Fwd: vboxsharedfs - Too many levels of symbolic links
Sun Dec 5 10:36:37 GMT 2021
On 2021-12-05 04:54, Takashi Yano wrote:
> 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:
> Is this the right thing?
> -- Takashi Yano
I can confirm that the patch fixes the issue with VirtualBox shared
More information about the Cygwin