Re: bash from local mounted drive with subst command

[Takashi Yano <takashi.yano@nifty.ne.jp>]

On Mon, 21 Feb 2022 01:05:32 +0100
Thomas Wolff wrote:
> 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

Ah, indeed, mount --bind a/b/c c in Linux does not behave
like this.

Corinna, what do you think?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>