Re: vboxsharedfs - Too many levels of symbolic links

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

On Dec  8 00:32, Takashi Yano wrote:
> On Tue, 7 Dec 2021 15:57:56 +0100
> Corinna Vinschen wrote:
> > On Dec  7 09:46, Takashi Yano wrote:
> > > I think '/cygdrive/z/..' should be '/cygdrive', however,
> > > in current cygwin, it is interpreted into '//VBoxSrv'.
> > > 
> > > Is this as you intended?
> > > 
> > > With my patch which stops to treat UNC path as symlink,
> > > '/cygdrive/z/..' returns '/cygdrive'.
> > 
> > Yeah, but...
> > 
> > ...what bugs me is that *every* UNC path is treated this way with
> > that patch.  If you have a path like /cygdrive/x/a/b/c, with x:
> > being a virtual drive pointing to //server/share, and with "b"
> > being a symlink to "syml", what you get back is either
> > 
> >   //server/share/a/syml/c
> > 
> > without, or
> > 
> >   /cygdrive/x/a/b/c
> > 
> > with your patch.  What we would like to get back is
> > 
> >   /cygdrive/x/a/syml/c
> 
> With my patch, above case behaves like:
> 
> $ mount
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
> $ cd /cygdrive/z
> $ mkdir -p aa/syml/cc
> $ ln -s syml aa/bb
> $ cd aa/bb/cc
> $ /bin/pwd
> /cygdrive/z/aa/syml/cc
> $
> 
> Isn't this what you would like?

Sorry, I wasn't expressing myself clearly.  The end result is what is
expected, yes.  But that's the result of the full path_conv conversion,
which wasn't what I was up to.

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.


Corinna