fsmonitor: handle differences between Windows named pipe functions #1503
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
There are issues in commit 3c88fcc: |
edecosta-mw
force-pushed
the
fsmonitor_windows
branch
from
3c88fcc to
51c47f8
Compare
|
There are issues in commit 51c47f8: |
edecosta-mw
force-pushed
the
fsmonitor_windows
branch
3 times, most recently
from
4697dab to
f9029b3
Compare
edecosta-mw
changed the title
edecosta-mw
force-pushed
the
fsmonitor_windows
branch
3 times, most recently
from
cf54907 to
c530792
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
This branch is now known as |
|
This patch series was integrated into seen via git@1f8f672. |
|
On the Git mailing list, Johannes Schindelin wrote (reply to this): Hi Eric,
On Fri, 24 Mar 2023, Eric DeCosta via GitGitGadget wrote:
> From: Eric DeCosta <[email protected]>
>
> 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). |
|
User |
|
On the Git mailing list, Jeff Hostetler wrote (reply to this): 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 <[email protected]>
>>
>> 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
|
|
User |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): Jeff Hostetler <[email protected]> writes:
>> This is a rather large deviation from the other platforms, and it
>> has an
>> unwanted side effect: Git for Windows' installer currently enumerates the
> ...
> Agreed. Please use forward slashes.
Thanks, both.
I'll mark the topic to be expecting a reroll, then.
|
|
This patch series was integrated into seen via git@33a9961. |
|
This patch series was integrated into seen via git@cff2f46. |
|
This patch series was integrated into seen via git@8ee0821. |
|
This patch series was integrated into seen via git@e6089c2. |
|
This patch series was integrated into seen via git@43553c3. |
|
This patch series was integrated into seen via git@57f7395. |
|
There was a status update in the "New Topics" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
This patch series was integrated into seen via git@33c3075. |
|
This patch series was integrated into seen via git@5468950. |
|
This patch series was integrated into seen via git@6ad792e. |
|
There was a status update in the "Cooking" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Cooking" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Cooking" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
On the Git mailing list, Eric DeCosta wrote (reply to this): > -----Original Message-----
> From: Jeff Hostetler <[email protected]>
> Sent: Wednesday, April 26, 2023 4:34 PM
> To: Eric DeCosta <[email protected]>; Eric DeCosta via GitGitGadget
> <[email protected]>; [email protected]
> Cc: Johannes Schindelin <[email protected]>
> Subject: Re: [PATCH v2] fsmonitor: handle differences between Windows
> named pipe functions
>
>
>
> On 4/22/23 4:00 PM, Eric DeCosta wrote:
> >
> >> -----Original Message-----
> >> From: Eric DeCosta via GitGitGadget <[email protected]>
> >> Sent: Monday, April 10, 2023 3:46 PM
> >> To: [email protected]
> >> Cc: Johannes Schindelin <[email protected]>; Jeff Hostetler
> >> <[email protected]>; Eric DeCosta <[email protected]>; Eric
> >> DeCosta <[email protected]>
> >> Subject: [PATCH v2] fsmonitor: handle differences between Windows
> named
> >> pipe functions
> >>
> >> From: Eric DeCosta <[email protected]>
> >>
> >> The two functions involved with creating and checking for the existance of
> >> the local fsmonitor named pipe, CratedNamedPipeW and
> WaitNamedPipeW
> >> appear to handle names with leading slashes or backslashes a bit
> differently.
> >>
> >> If a repo resolves to a remote file system with the UNC path of //some-
> >> server/some-dir/some-repo, CreateNamedPipeW accepts this name and
> >> creates this named pipe: \\.\pipe\some-server\some-dir\some-repo
> >>
> >> However, when the same UNC path is passed to WaitNamedPipeW, it fails
> >> with ERROR_FILE_NOT_FOUND.
> >>
> >> Skipping the leading slash for UNC paths works for both
> CreateNamedPipeW
> >> and WaitNamedPipeW. Resulting in a named pipe with the same name as
> >> above that WaitNamedPipeW is able to correctly find.
> >>
> >> Signed-off-by: Eric DeCosta <[email protected]>
> [...]
> >>
> >>
> >> compat/simple-ipc/ipc-win32.c | 7 ++++++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/compat/simple-ipc/ipc-win32.c b/compat/simple-ipc/ipc-
> win32.c
> >> index 997f6144344..632b12e1ab5 100644
> >> --- a/compat/simple-ipc/ipc-win32.c
> >> +++ b/compat/simple-ipc/ipc-win32.c
> >> @@ -19,13 +19,18 @@
> >> static int initialize_pipe_name(const char *path, wchar_t *wpath, size_t
> >> alloc) { int off = 0;
> >> + int real_off = 0;
> >> struct strbuf realpath = STRBUF_INIT;
> >>
> >> if (!strbuf_realpath(&realpath, path, 0)) return -1;
> >>
> >> + /* UNC Path, skip leading slash */
> >> + if (realpath.buf[0] == '/' && realpath.buf[1] == '/') real_off = 1;
> >> +
> >> off = swprintf(wpath, alloc, L"\\\\.\\pipe\\");
> >> - if (xutftowcs(wpath + off, realpath.buf, alloc - off) < 0)
> >> + if (xutftowcs(wpath + off, realpath.buf + real_off, alloc - off) < 0)
> >> return -1;
>
> I haven't had a chance to test this, but this does look
> like a minimal solution for the pathname confusion in the
> MSFT APIs.
>
> Do you need to test for realpath.buf[0] and [1] being a forward OR
> a backslash ?
>
> Should we set real_off to 2 rather than 1 because we already
> appended a trailing backslash in the swprintf() ?
>
Attempts to add additional backslashes after \\.\pipe\\ are apparently
ignored. The name of the local pipe always ends up looking like this:
for UNC paths:
\\.\pipe\\some-server\some-dir\some-repo
and for local paths:
\\.\pipe\\C_\some-dir\some-repo
Thus for a UNC path of //some-server/some-dir/some-repo the simplest thing to
do is to skip the first slash.
> You should run one of those NPFS directory listing tools to
> confirm the exact spelling of the pipe matches your expectation
> here. Yes, if both functions now work, we should be good, but
> it would be good to confirm your real_off choice, right?
>
I have used both PowerShell and Process Explorer and see similar results.
> If would be good to (at least interactively) test that the
> git-for-windows installer can find the path and stop the daemon
> on an upgrade or uninstall. See Johannes' earlier point.
>
In regards to the GfW installer, if the daemon is running against
a network mounted repo it reports the following:
Could not stop FSMonitor daemon in some-server\some-dir\some-repo
(output: , errors: fatal cannot change to 'some-server\some-dir\some-repo':
No such file or directory)
It looks like the installer may have to do something like:
look for "<drive letter>_" immediately after "\\.\pipe\\" and if it does not
find it, assume a UNC path.
> We should state somewhere that we are running the fsmonitor
> daemon locally and it is watching a remote file system.
>
> You should run a few stress tests to ensure that the
> MAX_RDCW_BUF_FALLBACK throttling works and that the daemon
> doesn't fall behind on a very busy remote file system. (There
> are SMB/CIFS wire protocol limits. See the source.) (I did
> test this between the combination of systems that I had, but
> YMMV.)
>
> During the stress test, it would also be good to test that
> IO generated by a client process on your local machine to the
> remote file system is reported, but also that random IO from
> remote processes on the remote system are seen in the event
> stream. Again, I tested the combinations of machines that I
> had available at the time.
>
I hear what you are saying, however reporting that information increases
the scope of this change. As this stands right now the advertised feature
of allowing fsmonitor to work on network-mounted sandboxes for Windows
is not working as expected.
-Eric
> Hope this helps,
> Jeff
>
>
> >>
> >> /* Handle drive prefix */
> >>
> >> base-commit: f285f68a132109c234d93490671c00218066ace9
> >> --
> >> gitgitgadget
> >
> > Are there any other thoughts about this?
> >
> > I believe that this is the simplest change possible that will ensure that
> > fsmonitor correctly handles network repos.
> >
> > -Eric
|
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
On the Git mailing list, Jeff Hostetler wrote (reply to this): Sorry this got lost in my inbox.
On 5/8/23 4:30 PM, Eric DeCosta wrote:
> >> -----Original Message-----
>> From: Jeff Hostetler <[email protected]>
>> Sent: Wednesday, April 26, 2023 4:34 PM
>> To: Eric DeCosta <[email protected]>; Eric DeCosta via GitGitGadget
>> <[email protected]>; [email protected]
>> Cc: Johannes Schindelin <[email protected]>
>> Subject: Re: [PATCH v2] fsmonitor: handle differences between Windows
>> named pipe functions
>>
>>
>>
>> On 4/22/23 4:00 PM, Eric DeCosta wrote:
>>>
>>>> -----Original Message-----
>>>> From: Eric DeCosta via GitGitGadget <[email protected]>
>>>> Sent: Monday, April 10, 2023 3:46 PM
>>>> To: [email protected]
>>>> Cc: Johannes Schindelin <[email protected]>; Jeff Hostetler
>>>> <[email protected]>; Eric DeCosta <[email protected]>; Eric
>>>> DeCosta <[email protected]>
>>>> Subject: [PATCH v2] fsmonitor: handle differences between Windows
>> named
>>>> pipe functions
>>>>
>>>> From: Eric DeCosta <[email protected]>
>>>>
>>>> The two functions involved with creating and checking for the existance of
>>>> the local fsmonitor named pipe, CratedNamedPipeW and
>> WaitNamedPipeW
>>>> appear to handle names with leading slashes or backslashes a bit
>> differently.
>>>>
>>>> If a repo resolves to a remote file system with the UNC path of //some-
>>>> server/some-dir/some-repo, CreateNamedPipeW accepts this name and
>>>> creates this named pipe: \\.\pipe\some-server\some-dir\some-repo
>>>>
>>>> However, when the same UNC path is passed to WaitNamedPipeW, it fails
>>>> with ERROR_FILE_NOT_FOUND.
>>>>
>>>> Skipping the leading slash for UNC paths works for both
>> CreateNamedPipeW
>>>> and WaitNamedPipeW. Resulting in a named pipe with the same name as
>>>> above that WaitNamedPipeW is able to correctly find.
>>>>
>>>> Signed-off-by: Eric DeCosta <[email protected]>
>> [...]
>>>>
>>>>
>>>> compat/simple-ipc/ipc-win32.c | 7 ++++++-
>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/compat/simple-ipc/ipc-win32.c b/compat/simple-ipc/ipc-
>> win32.c
>>>> index 997f6144344..632b12e1ab5 100644
>>>> --- a/compat/simple-ipc/ipc-win32.c
>>>> +++ b/compat/simple-ipc/ipc-win32.c
>>>> @@ -19,13 +19,18 @@
>>>> static int initialize_pipe_name(const char *path, wchar_t *wpath, size_t
>>>> alloc) { int off = 0;
>>>> + int real_off = 0;
>>>> struct strbuf realpath = STRBUF_INIT;
>>>>
>>>> if (!strbuf_realpath(&realpath, path, 0)) return -1;
>>>>
>>>> + /* UNC Path, skip leading slash */
>>>> + if (realpath.buf[0] == '/' && realpath.buf[1] == '/') real_off = 1;
>>>> +
>>>> off = swprintf(wpath, alloc, L"\\\\.\\pipe\\");
>>>> - if (xutftowcs(wpath + off, realpath.buf, alloc - off) < 0)
>>>> + if (xutftowcs(wpath + off, realpath.buf + real_off, alloc - off) < 0)
>>>> return -1;
>>
>> I haven't had a chance to test this, but this does look
>> like a minimal solution for the pathname confusion in the
>> MSFT APIs.
>>
>> Do you need to test for realpath.buf[0] and [1] being a forward OR
>> a backslash ?
>>
>> Should we set real_off to 2 rather than 1 because we already
>> appended a trailing backslash in the swprintf() ?
>>
> Attempts to add additional backslashes after \\.\pipe\\ are apparently
> ignored. The name of the local pipe always ends up looking like this:
> > for UNC paths:
> \\.\pipe\\some-server\some-dir\some-repo
> > and for local paths:
> \\.\pipe\\C_\some-dir\some-repo
> > Thus for a UNC path of //some-server/some-dir/some-repo the simplest thing to
> do is to skip the first slash.
Ok thanks. Just being paranoid...
> >> You should run one of those NPFS directory listing tools to
>> confirm the exact spelling of the pipe matches your expectation
>> here. Yes, if both functions now work, we should be good, but
>> it would be good to confirm your real_off choice, right?
>>
> I have used both PowerShell and Process Explorer and see similar results.
> good. thanks.
>> If would be good to (at least interactively) test that the
>> git-for-windows installer can find the path and stop the daemon
>> on an upgrade or uninstall. See Johannes' earlier point.
>>
> In regards to the GfW installer, if the daemon is running against
> a network mounted repo it reports the following:
> > Could not stop FSMonitor daemon in some-server\some-dir\some-repo
> (output: , errors: fatal cannot change to 'some-server\some-dir\some-repo':
> No such file or directory)
> > It looks like the installer may have to do something like:
> look for "<drive letter>_" immediately after "\\.\pipe\\" and if it does not
> find it, assume a UNC path.
> ok. perhaps you could log an issue on github.com/git-for-windows/git.git
to describe this.
>> We should state somewhere that we are running the fsmonitor
>> daemon locally and it is watching a remote file system.
>>
>> You should run a few stress tests to ensure that the
>> MAX_RDCW_BUF_FALLBACK throttling works and that the daemon
>> doesn't fall behind on a very busy remote file system. (There
>> are SMB/CIFS wire protocol limits. See the source.) (I did
>> test this between the combination of systems that I had, but
>> YMMV.)
>>
>> During the stress test, it would also be good to test that
>> IO generated by a client process on your local machine to the
>> remote file system is reported, but also that random IO from
>> remote processes on the remote system are seen in the event
>> stream. Again, I tested the combinations of machines that I
>> had available at the time.
>>
> I hear what you are saying, however reporting that information increases
> the scope of this change. As this stands right now the advertised feature
> of allowing fsmonitor to work on network-mounted sandboxes for Windows
> is not working as expected.
understood. my only concern was that remotely mounted file systems
didn't get a lot of testing. it worked, but i didn't have resources
to really stress it. but then again, it if falls behind it will
force a resync, so you *shouldn't* get a wrong answer.
Thanks for all your work (and patience with me) on this.
Jeff
> > -Eric
> >> Hope this helps,
>> Jeff
>>
>>
>>>>
>>>> /* Handle drive prefix */
>>>>
>>>> base-commit: f285f68a132109c234d93490671c00218066ace9
>>>> --
>>>> gitgitgadget
>>>
>>> Are there any other thoughts about this?
>>>
>>> I believe that this is the simplest change possible that will ensure that
>>> fsmonitor correctly handles network repos.
>>>
>>> -Eric
> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Expecting a reroll. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Will discard. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Will discard. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Stalled" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Will discard. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Discarded" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Discarded" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There was a status update in the "Discarded" section about the branch Fix fsmonitor on Windows when the filesystem path contains certain characters. Have been expecting a reroll for too long. cf. <[email protected]> source: <[email protected]> |
|
There is a merge commit in this Pull Request: Please rebase the branch and force-push. |
@edecosta-mw please rebase onto |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The two functions involved with creating and checking for the existance of the local fsmonitor named pipe, CratedNamedPipeW and WaitNamedPipeW appear to handle names with leading slashes or backslashes a bit differently.
If a repo resolves to a remote file system with the UNC path of //some-server/some-dir/some-repo, CreateNamedPipeW accepts this name and creates this named pipe: .\pipe\some-server\some-dir\some-repo
However, when the same UNC path is passed to WaitNamedPipeW, it fails with ERROR_FILE_NOT_FOUND.
Skipping the leading slash for UNC paths works for both CreateNamedPipeW and WaitNamedPipeW. Resulting in a named pipe with the same name as above that WaitNamedPipeW is able to correctly find.
v1 differs from v0:
cc: Johannes Schindelin [email protected]
cc: Jeff Hostetler [email protected]