From: Thomas Wolff <towo@towo.net>
To: cygwin@cygwin.com
Subject: Re: bash from local mounted drive with subst command
Date: Mon, 21 Feb 2022 01:05:32 +0100 [thread overview]
Message-ID: <4ff0ff80-c024-e8b3-c6d0-b8cc789f6b08@towo.net> (raw)
In-Reply-To: <20220221085629.db8678da50910b5255981705@nifty.ne.jp>
Am 21.02.2022 um 00:56 schrieb Takashi Yano:
> On Mon, 21 Feb 2022 08:41:52 +0900
> Takashi Yano wrote:
>> 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?
> The similar happens also in Linux.
>
> In Debuan GNU/Linux 11.2:
> yano@debian:~$ mkdir -p a/b/c
> yano@debian:~$ ln -s a/b/c c
> yano@debian:~$ cd c
> yano@debian:~/c$ pwd
> /home/yano/c
> yano@debian:~/c$ /bin/pwd
> /home/yano/a/b/c
>
> In cygwin 3.3.4:
> yano@cygwin:~$ mkdir -p a/b/c
> yano@cygwin:~$ ln -s a/b/c c
> yano@cygwin:~$ cd c
> yano@cygwin:~/c$ pwd
> /home/yano/c
> yano@cygwin:~/c$ /bin/pwd
> /home/yano/a/b/c
pwd -P will also work like /bin/pwd - but: subst is more comparable to
mount than to ln -s
next prev parent reply other threads:[~2022-02-21 0:05 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
2022-02-20 23:56 ` Takashi Yano
2022-02-21 0:05 ` Thomas Wolff [this message]
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=4ff0ff80-c024-e8b3-c6d0-b8cc789f6b08@towo.net \
--to=towo@towo.net \
--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).