Re: vboxsharedfs - Too many levels of symbolic links

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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-cygwin@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