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

[Eric DeCosta <edecosta@mathworks.com>]

> -----Original Message-----
> From: Jeff Hostetler <git@jeffhostetler.com>
> Sent: Monday, March 27, 2023 11:02 AM
> To: Johannes Schindelin <Johannes.Schindelin@gmx.de>; Eric DeCosta via
> GitGitGadget <gitgitgadget@gmail.com>
> Cc: git@vger.kernel.org; Eric DeCosta <edecosta@mathworks.com>
> Subject: Re: [PATCH] fsmonitor: handle differences between Windows
> named pipe functions
> 
> 
> 
> 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 <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).
> 
> Agreed. Please use forward slashes.
> 
> Thanks,
> Jeff
> 

I have misdiagnosed the problem. Here are my most recent findings:

The problem is the leading double-slashes for repos that resolve to remote filesystems. i.e. if S:\myrepo resolves to \\some-server\some-dir\myrepo then the path passed to initialize_pipe_name is //some-server/some-dir/myrepo

Regardless of what type or how many slashes appear after \\.\pipe\ the pipe name, as reported from PowerShell, is always \\.\\pipe\\some-server\some-dir\myrepo and WaitNamedPipeW returns ERROR_FILE_NOT_FOUND

If I skip over the first leading slash an use /some-server/some-dir/myrepo I get the same pipe name as before, WaitNamedPipeW is happy and commands like git fsmonitor--daemon status correctly report that the daemon is watching the repo.

-Eric