DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6C143858424
Date: Thu, 2 Dec 2021 11:43:27 +0100
To: cygwin@cygwin.com
Subject: Re: vboxsharedfs - Too many levels of symbolic links
Message-ID: <YaijT+axSUYJKNTM@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <d6470ffe-8e49-3eb7-4d21-3212e0ad4f31@oskog97.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d6470ffe-8e49-3eb7-4d21-3212e0ad4f31@oskog97.com>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On Nov 30 19:04, 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

Somebody will have to debug this.  From the MSYS issue it looks like the
GetFinalPathNameByHandleW call results in some trouble, but the MSYS
guys rather just disable code instead of trying to debug it and fixing
the cause.

"Somebody" would have to be somebody who can reproduce the issue.  I'm
neither using VirtualBox, nor AFS.

I probably could test this if somebody gives me temporary access to an
existing AFS FS somewhere, plus a short description how to connect.
I guess it starts with "Install latest OpenAFS version x.y for Windows"...


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