bash from local mounted drive with subst command
Takashi Yano
takashi.yano@nifty.ne.jp
Sun Feb 20 23:56:29 GMT 2022
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
--
Takashi Yano <takashi.yano@nifty.ne.jp>
More information about the Cygwin
mailing list