From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: Symbolic link bug in recent Cygwin DLL build
Date: Tue, 21 Apr 2020 10:08:33 +0200 [thread overview]
Message-ID: <20200421080833.GS3943@calimero.vinschen.de> (raw)
In-Reply-To: <1982edcf-1e01-9e59-7895-f0f4f7c7d058@maxrnd.com>
On Apr 21 00:15, Mark Geisert wrote:
> Corinna Vinschen wrote:
> > On Apr 16 20:10, Mark Geisert wrote:
> > > [...]
> > > none / cygdrive binary,posix=0,user 0 0
> > > [...]
> > 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?
> > [...]
> > $ 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.
We can't do that these days without breaking lots of installations
already using this prefix.
> You want I should submit a patch for solution 3?
No, the patch is really simple and I already have it in the loop.
However, to get the full functionality it might still be a good idea to
change the cygdrive prefix to something else(*) and use symlinks to
/proc/cygdrive/X in / instead.
Thanks,
Corinna
(*) Funny enough I'm using /mnt as cygdrive prefix for ages... which
means, I had to change it to something else first, otherwise I
wouldn't have been able to test if the WSL symlinks are doing the
right thing in terms of cygdrive prefix translation...
--
Corinna Vinschen
Cygwin Maintainer
prev parent reply other threads:[~2020-04-21 8:08 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
2020-04-21 8:08 ` Corinna Vinschen [this message]
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=20200421080833.GS3943@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.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).