On Dec 8 17:20, Takashi Yano wrote:
> On Tue, 7 Dec 2021 18:15:42 +0100
> Corinna Vinschen wrote:
> > Hi Takashi,
> >
> > ----- Forwarded message from Corinna Vinschen <corinna-cyg...@cygwin.com>
> > -----
> > > The idea of the GFPNBH call is to short-circuit the path_conv handling
> > > in case we have native Windows symlinks in the path. My example above
> > > was only considering what comes out of the `if ((pc_flags & ...) { ... }
> > > ' expression starting in line 3485 (assuming "b" is a native symlink).
> > >
> > > What I mean is this: Your patch disregards the entire string returned by
> > > GFPNBH, if the returned path is an UNC path, no matter what.
> > >
> > > But what if the incoming path already *was* an UNC path, and potentially
> > > contains native symlinks? In that case you have no reason to disregard
> > > the resulting path from GFPNBH.
> > >
> > > And if it was a drive letter path, wouldn't it be nicer to just convert
> > > the UNC path prefix back to the drive letter and keep the rest of the
> > > final path intact?
> > >
> > > However, both of these scenarios require extra code, which isn't that
> > > important for now, so, never mind.
> > ----- End forwarded message -----
> >
> > What I meant is something like the below (entirely untested). Yeah, I'm
> > not sure myself, if it's worth the effort...
> > [...]
> I confirmed that your patch works nicely.
>
> ...except when the drive is created by subst using UNC path,
> e.g. subst w: \\server\share.
>
> In this case, WNetGetConnectionW() fails with ERROR_NO_NET_OR_BAD_PATH.
>
> So, I modified your patch a bit.
>
> What about attached patch?
Oh, great! GetVolumePathNameW is the function I somehow missed when
looking into the Microsoft docs yesterday, so thanks for modifying the
patch this way.
Please push.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
