vboxsharedfs - Too many levels of symbolic links

[Takashi Yano]

On Tue, 30 Nov 2021 19:04:57 +0200
Oskar Skog wrote:
> vboxsharedfs file systems no longer work. Any attempt to access will
> result in "too many levels of symbolic links".
> 
> This only affects the VirtualBox shared folder, the Samba share works
> just fine.
> 
> Last time I updated (before today) was sometime before the 10th of
> September.
> 
> MSYS2 has the same problem, but no one seems to have reported it to
> Cygwin:
> https://github.com/msys2/msys2-runtime/issues/58
> 
> 
> user@DESKTOP-******* ~$ ls /cygdrive/z
> ls: cannot access '/cygdrive/z': Too many levels of symbolic links
> user@DESKTOP-******* ~$ 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)
> Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs 
> (binary,posix=0,user,noumount,auto)
> user@DESKTOP-******* ~$ uname -a
> CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin

Thanks for the report.
It seems that this happens only in 64bit Windoes10/11.

In 32bit Windows10:
$ ls -l /cygdrive/z
total 0
-rw-r--r-- 1 yano yano 0 Dec  3 22:16 testfile.txt
$ 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)
$ uname -a
CYGWIN_NT-10.0 DESKTOP-HGUT5FP 3.3.2(0.341/5/3) 2021-11-08 16:51 i686 Cygwin

In 64bit Windows10:
$ ls -l /cygdrive/z
ls: /cygdrive/z: Too many levels of symbolic links
ls: cannot open directory '/cygdrive/z': Too many levels of symbolic links
$ 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)
Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
$ uname -a
CYGWIN_NT-10.0-WOW DESKTOP-CUHC1NV 3.3.2(0.341/5/3) 2021-11-08 16:51 i686 Cygwin

I tested with VirtualBox version 6.1.30.

In 64bit Windows10, for vbox shared path, GetFinalPathNameByHandleW()
returns path with trailing '\'. As a result, RtlEqualUnicodeString()
fails and tries to resolve symlink repeatedly.

For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
\??\UNC\VBoxSrv\tmp\, then it fails.

This does not happen in 32bit Windows10. It seems that UNC path is not
treated as a symlink in 32bit Windows10. I am not sure why.

Therefore, I have applied a patch which stops to treat UNC path as a
symlink for testing as follows.

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index baf04ce89..31a96ca58 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3490,6 +3490,9 @@ restart:
 	  ret = GetFinalPathNameByHandleW (h, fpbuf, NT_MAX_PATH, 0);
 	  if (ret)
 	    {
+	      if (wcsstr (fpbuf, L"\\\\?\\UNC\\") == fpbuf)
+		goto file_not_symlink;
+
 	      UNICODE_STRING fpath;
 
 	      RtlInitCountedUnicodeString (&fpath, fpbuf, ret * sizeof (WCHAR));

I have confirmed this patch fixes the issue. In addition, this patch
also resolves the issue:
https://cygwin.com/pipermail/cygwin/2021-December/250103.html

Is this the right thing?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>