public inbox for
 help / color / mirror / Atom feed
From: Takashi Yano <>
Subject: Re: bash from local mounted drive with subst command
Date: Mon, 21 Feb 2022 08:56:29 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 <>
> 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 <>
> 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
yano@debian:~/c$ /bin/pwd

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
yano@cygwin:~/c$ /bin/pwd

Takashi Yano <>

  reply	other threads:[~2022-02-20 23:56 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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).