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

- From: Jeff Hostetler \<hidden\>
- Date: 2023-03-27 15:03:32 
- List: git
- Page: https://ratatoskr.run/git/2023/03/7967271
- Thread: https://ratatoskr.run/git/2023/03/7967135/t.md

```text


On 3/27/23 7:37 AM, Johannes Schindelin wrote:
> Hi Eric,
>
> On Fri, 24 Mar 2023, Eric DeCosta via GitGitGadget wrote:
>
>> From: Eric DeCosta <redacted>
>>
>> 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).

Agreed. Please use forward slashes.

Thanks,
Jeff


```