Re: [PATCH] fsmonitor: handle differences between Windows named pipe functions

> Hi Eric,
> 
> On Fri, 24 Mar 2023, Eric DeCosta via GitGitGadget wrote:
> 
>> From: Eric DeCosta <edecosta@mathworks.com>
>>
>> CreateNamedPipeW is perfectly happy accepting pipe names with seemingly
>> embedded escape charcters (e.g. \b), WaitNamedPipeW is not and incorrectly
>> returns ERROR_FILE_NOT_FOUND when clearly a named pipe, succesfully created
>> with CreateNamedPipeW, exists.
>>
>> For example, this network path is problemmatic:
>> \\batfs-sb29-cifs\vmgr\sbs29\my_git_repo
>>
>> In order to work around this issue, rather than using the path to the
>> worktree directly as the name of the pipe, instead use the hash of the
>> worktree path.
> 
> This is a rather large deviation from the other platforms, and it has an
> unwanted side effect: Git for Windows' installer currently enumerates the
> named pipes to figure out which FSMonitor instances need to be stopped
> before upgrading. It has to do that because it would otherwise be unable
> to overwrite the Git executable. And it needs to know the paths [*1*] so
> that it can stop the FSMonitors gracefully (as opposed to terminating them
> and risk interrupting them while they serve a reply to a Git client).
> 
> A much less intrusive change (that would not break Git for Windows'
> installer) would be to replace backslashes by forward slashes in the path.
> 
> Please do that instead.
> 
> Ciao,
> Johannes
> 
> Footnote *1*: If you think that the Git for Windows installer could simply
> enumerate the process IDs of the FSMonitor instances and then look for
> their working directories: That is not a viable option. Not only does the
> Windows-based FSMonitor specifically switch to the parent directory (to
> avoid blocking the removal of a Git directory merely by running the
> process in said directory), even worse: there is no officially-sanctioned
> way to query a running process' current working directory (the only way I
> know of involves injecting a remote thread! Which will of course risk
> being labeled as malware by current anti-malware solutions).