From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: bash from local mounted drive with subst command
Date: Mon, 21 Feb 2022 08:41:52 +0900 [thread overview]
Message-ID: <20220221084152.d4ffc040ec085f001f1fad0d@nifty.ne.jp> (raw)
In-Reply-To: <CACR4mKVj1SAO04iFOukMKEkD0YNUUD=x3Gh4Ypz8TQaPYx=6TA@mail.gmail.com>
On Sun, 20 Feb 2022 22:38:53 +0100
Claude TETE wrote:
> A bash in a local mounted drive, use realpath instead of mounted one
> for all child processes.
>
> Example, mount a local folder on Z: drive, go in there and run any
> external command:
> $ subst Z: C:\\Users
> $ cd /cygdrive/z/
> $ /bin/pwd
> /cygdrive/c/Users
>
> Expected
> /cygdrive/w
This is since:
commit 19d59ce75d5301ae167b421111d77615eb307aa7
Author: Corinna Vinschen <corinna@vinschen.de>
Date: Fri May 7 16:07:03 2021 +0200
Cygwin: path_conv: Rework handling native symlinks as inner path components
commit 456c3a46386f was only going half-way. It handled symlinks and
junction points as inner path components and made realpath return the
correct path, but it ignored drive letter substitution, i. e., virtual
drives created with, e. g.
subst X: C:\foo\bar
It was also too simple. Just returning an error code from
symlink_info::check puts an unnecessary onus on the symlink evaluation
loop in path_conv::check.
Rework the code to use GetFinalPathNameByHandle, and only do this after
checking the current file for being a symlink failed.
If the final path returned by GetFinalPathNameByHandle is not the same
as the incoming path, replace the incoming path with the POSIXified
final path. This also short-circuits path evaluation, because
path_conv::check doesn't have to recurse over the inner path components
multiple times if all symlinks are of a native type, while still getting
the final path as end result.
Virtual drives are now handled like symlinks. This is a necessary change
from before to make sure virtual drives are handled identically across
different access methods. An example is realpath(1) from coreutils. It
doesn't call readlink(2), but iterates over all path components using
lstat/readlink calls. Both methods should result in the same real path.
Fixes: 456c3a46386f ("path_conv: Try to handle native symlinks more sanely")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The behaviour is by design. Does this cause any practical issue?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
next prev parent reply other threads:[~2022-02-20 23:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-20 21:38 Claude TETE
2022-02-20 23:41 ` Takashi Yano [this message]
2022-02-20 23:56 ` Takashi Yano
2022-02-21 0:05 ` Thomas Wolff
2022-02-21 0:40 ` Takashi Yano
2022-02-21 11:13 ` Corinna Vinschen
2022-03-07 19:36 ` Andrey Repin
2022-09-19 20:40 David Meyer
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=20220221084152.d4ffc040ec085f001f1fad0d@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).