Hi Eric, On Fri, 24 Mar 2023, Eric DeCosta via GitGitGadget wrote: > From: Eric DeCosta <edecosta@xxxxxxxxxxxxx> > > 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).
