From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: vboxsharedfs - Too many levels of symbolic links
Date: Mon, 6 Dec 2021 19:55:27 +0900 [thread overview]
Message-ID: <20211206195527.9b9c09b549fa8fcc2512949e@nifty.ne.jp> (raw)
In-Reply-To: <Ya3i/sfWB2avaJ9F@calimero.vinschen.de>
On Mon, 6 Dec 2021 11:16:30 +0100
Corinna Vinschen wrote:
> > For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
> > \??\UNC\VBoxSrv\tmp\, then it fails.
> > [...]
> > + if (wcsstr (fpbuf, L"\\\\?\\UNC\\") == fpbuf)
> > + goto file_not_symlink;
> > +
>
> Isn't that a bit intrusive? Wouldn't it also fix the issue if we
> just overwrite a trailing '\\' with '\0', like this?
>
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index baf04ce89a08..b76e5b0466cf 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -3492,8 +3492,14 @@ restart:
> {
> UNICODE_STRING fpath;
>
> - RtlInitCountedUnicodeString (&fpath, fpbuf, ret * sizeof (WCHAR));
> + /* If incoming path has no trailing backslash, but final path
> + has one, drop trailing backslash from final path so the
> + below string comparison has a chance to succeed. */
> + if (upath.Buffer[(upath.Length - 1) / sizeof (WCHAR)] != L'\\'
> + && fpbuf[ret - 1] == L'\\')
> + fpbuf[--ret] = L'\0';
> fpbuf[1] = L'?'; /* \\?\ --> \??\ */
> + RtlInitCountedUnicodeString (&fpath, fpbuf, ret * sizeof (WCHAR));
> if (!RtlEqualUnicodeString (&upath, &fpath, !!ci_flag))
> {
> issymlink = true;
First, I think the same. However, with this patch, it sometimes causes
hang for a few seconds around the code:
else if (isvirtual_dev (dev))
{
/* FIXME: Calling build_fhandler here is not the right way to
handle this. */
fhandler_virtual *fh = (fhandler_virtual *)
build_fh_dev (dev, path_copy);
virtual_ftype_t file_type;
if (!fh)
file_type = virt_none;
else
{
file_type = fh->exists ();
if (file_type == virt_symlink
|| file_type == virt_fdsymlink)
{
fh->fill_filebuf ();
symlen = sym.set (fh->get_filebuf ());
}
with path_copy of "//VBoxSrv". I am not sure why.
In addition,
https://cygwin.com/pipermail/cygwin/2021-December/250103.html
still needs fix.
So I proposed the patch which stops to treat UNC path as symlink.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
next prev parent reply other threads:[~2021-12-06 10:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 17:04 Oskar Skog
2021-11-30 21:40 ` Gackle, Philip P
2021-12-02 10:43 ` Corinna Vinschen
2021-12-05 2:54 ` Takashi Yano
2021-12-05 14:49 ` Oskar Skog
2021-12-06 3:31 ` Takashi Yano
2021-12-06 6:34 ` Oskar Skog
2021-12-06 8:04 ` Takashi Yano
2021-12-06 10:16 ` Corinna Vinschen
2021-12-06 10:55 ` Takashi Yano [this message]
2021-12-07 0:46 ` Takashi Yano
2021-12-07 14:57 ` Corinna Vinschen
2021-12-07 15:32 ` Takashi Yano
2021-12-07 15:43 ` Takashi Yano
2021-12-07 16:03 ` Corinna Vinschen
[not found] <Ya+WvmECA+zAbuV9@calimero.vinschen.de>
2021-12-08 8:20 ` Takashi Yano
2021-12-08 10:37 ` Corinna Vinschen
2021-12-09 8:16 ` Takashi Yano
2021-12-09 9:16 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211206195527.9b9c09b549fa8fcc2512949e@nifty.ne.jp \
--to=takashi.yano@nifty.ne.jp \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).