From: Mark Geisert <mark@maxrnd.com>
To: cygwin-developers@cygwin.com
Subject: Re: Symbolic link bug in recent Cygwin DLL build
Date: Tue, 21 Apr 2020 00:15:44 -0700 [thread overview]
Message-ID: <1982edcf-1e01-9e59-7895-f0f4f7c7d058@maxrnd.com> (raw)
In-Reply-To: <20200417075016.GI3943@calimero.vinschen.de>
Corinna Vinschen wrote:
> On Apr 16 20:10, Mark Geisert wrote:
>> Sorry about the ML flub. Your mention of cygdrive prefix gave me some
>> dread. From day 1 I've suppressed the prefix on any Cygwin machine I've
>> administered; I use /c or /d etc to refer to drives. That means having this
>> line in /etc/fstab:
>> none / cygdrive binary,posix=0,user 0 0
>>
>> The "/mnt" is being added at path.cc:1892. It's replacing the current
>> cygdrive prefix with "/mnt".
>
> Ok, that explains it. It makes this function exactly this teeny little
> bit more complicated :-P
>
>> I'm unclear why we're in a function named
>> symlink_wsl() since I'm not using WSL at all. Maybe it means
>> WSL-compatible? OK if so.
>
> git log --grep symlinks d2e0b65a7fdc..HEAD >
>> Does that string replacement need to be skipped in this situation of "empty"
>> cygdrive prefix? Or is it something more subtle?
>
> It's a bit more subtil. The code also tries to convert the cygdrive
> prefix to /mnt if no drive letter follows, so you can create a symlink
> to the cygdrive directory alone:
>
> $ ln -s /cygdrive /tmp/cygdrive_symlink
>
> That also allowed the conversion cygdrive prefix to /mnt without having
> to look for the drive letters. Now, with the cygdrive prefix being /,
> the first path component has to be checked for being... what?
>
> - Just check for a single letter from a to z? That would also wrongly
> catch /x if /x is a real subdir in the root dir.
>
> - Check for an existing drive letter from a to z? That would break
> the symlink conversion on the WSL side if the symlink was supposed
> to be created pointing to, say, an USB thumb drive which was not
> plugged in at the time of the symlink creation.
>
> - Just skip any /mnt prefix if the cygdrive prefix is /? That would
> make all drive letter paths incompatible with WSL, and in contrast to
> /mnt symlinks, it does not autommagically "fix" drive letter paths
> if you ever change your cygdrive prefix, which is a neat side-effect
> of the new symlinks, IMHO.
>
> I'm leaning towards solution 3.
That seems OK to me but I don't have much depth of experience about possible
downsides. If it was instead decided that we need to require a "/path" for a
cygdrive prefix in /etc/fstab I would just go back to creating symlinks like /c
-> /cygdrive/c like I did long ago.
You want I should submit a patch for solution 3?
..mark
next prev parent reply other threads:[~2020-04-21 7:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.BSF.4.63.2004152345230.10561@m0.truegem.net>
2020-04-16 8:58 ` Corinna Vinschen
2020-04-17 3:10 ` Mark Geisert
2020-04-17 7:50 ` Corinna Vinschen
2020-04-21 7:15 ` Mark Geisert [this message]
2020-04-21 8:08 ` 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=1982edcf-1e01-9e59-7895-f0f4f7c7d058@maxrnd.com \
--to=mark@maxrnd.com \
--cc=cygwin-developers@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).