From: Jeff Hostetler Date: Mon, 27 Mar 2023 15:02:16 GMT Subject: Re: [PATCH] fsmonitor: handle differences between Windows named pipe functions Message-ID: In-Reply-To: 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 >> >> 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