X-Recipient: archive-cygwin AT delorie DOT com X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0C1E3858C83 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 21L0eEOJ029896 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1645404015; bh=AAj3ViQ71FVcnnPCLgku84mJhzc8GMUfOzgsI3wY938=; h=Date:From:To:Subject:In-Reply-To:References:From; b=gAibT/gPCxBB+qTI9BvvmNCJejtgIHNd/zndf8UhYo7zvt2U9twC07uqpVbx7tNXj Ubj5sQv+mFHZStGTYVnr5S/BDcUXhaEGUzFImM32i/pCFHKGf6nW1gchAq/MkBtOyB 9oIO1ZKHGW2MYmM4XQp5OnxmYpOcrIV8ytbP7a0wos5XEwpN1BQ1fapiyzbtmKlPa5 D2AxUQ4ej4hdYXUJp6xfMi3cbmAb2dkbyAdzhNcb7Tq+3GpXZcBH2SewT2BZmW+5oB 27EsTc1zwuQp+nIwh3ugjtLMsY3hav9B5fPHLmujB/RwlwlPwyvyofB0WY/b0PHfPt +g9hdMDXsoy5A== X-Nifty-SrcIP: [119.150.36.16] Date: Mon, 21 Feb 2022 09:40:23 +0900 From: Takashi Yano To: cygwin AT cygwin DOT com Subject: Re: bash from local mounted drive with subst command Message-Id: <20220221094023.9bfea8d8672be882b861d18b@nifty.ne.jp> In-Reply-To: <4ff0ff80-c024-e8b3-c6d0-b8cc789f6b08@towo.net> References: <20220221084152 DOT d4ffc040ec085f001f1fad0d AT nifty DOT ne DOT jp> <20220221085629 DOT db8678da50910b5255981705 AT nifty DOT ne DOT jp> <4ff0ff80-c024-e8b3-c6d0-b8cc789f6b08 AT towo DOT net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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 > >> 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 AT debian:~$ mkdir -p a/b/c > > yano AT debian:~$ ln -s a/b/c c > > yano AT debian:~$ cd c > > yano AT debian:~/c$ pwd > > /home/yano/c > > yano AT debian:~/c$ /bin/pwd > > /home/yano/a/b/c > > > > In cygwin 3.3.4: > > yano AT cygwin:~$ mkdir -p a/b/c > > yano AT cygwin:~$ ln -s a/b/c c > > yano AT cygwin:~$ cd c > > yano AT cygwin:~/c$ pwd > > /home/yano/c > > yano AT 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