Re: bash from local mounted drive with subst command
We're running into this same issue on my project. We're trying to shorten path names to get around Visual Studio limitations in path lengths, which are unfortunately very long for us since we're generating filenames based on package names and the like. If subst won't work to let us shorten path names, is there any other solution? We'd really like something that behaves like bind mounts rather than symlinks. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
Greetings, Claude TETE! > Hi all, > 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 Don't cd? > Expected > /cygdrive/w What is the PROBLEM, pretty please? The path is correct either way, so, what are you trying to fix? > Issue since Cygwin 3.3 and also with latest snapshot (2022-02-17 > 11:55:32) after reading this: > https://cygwin.com/pipermail/cygwin/2021-December/250153.html > https://cygwin.com/pipermail/cygwin-patches/2021q4/011583.html -- With best regards, Andrey Repin Monday, March 7, 2022 22:34:43 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
On Feb 21 09:40, Takashi Yano wrote: > On Mon, 21 Feb 2022 01:05:32 +0100 > Thomas Wolff wrote: > > 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? The reason for the patches hasn't changed. We can rip out all this stuff and revert to the older, erroneous behaviour, but why? The result is correct. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
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 19d59ce75d5301ae167b42d77615eb307aa7 > >> 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 > > /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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
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 19d59ce75d5301ae167b42d77615eb307aa7 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 /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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
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 19d59ce75d5301ae167b42d77615eb307aa7 > 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 /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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: bash from local mounted drive with subst command
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 19d59ce75d5301ae167b42d77615eb307aa7 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? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
bash from local mounted drive with subst command
Hi all, 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 Issue since Cygwin 3.3 and also with latest snapshot (2022-02-17 11:55:32) after reading this: https://cygwin.com/pipermail/cygwin/2021-December/250153.html https://cygwin.com/pipermail/cygwin-patches/2021q4/011583.html Sincerely, -- Claude TETE "Those who dream by day are cognizant of many things which escape those who dream only by night." Edgar Allan Poe. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple