From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id 758883858D37 for ; Tue, 2 Aug 2022 08:19:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 758883858D37 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N5W4y-1nLkK20m54-016xeq for ; Tue, 02 Aug 2022 10:19:44 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 557BDA80778; Tue, 2 Aug 2022 10:19:43 +0200 (CEST) Date: Tue, 2 Aug 2022 10:19:43 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Issues with Cygwin64 on Windows11 Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20220731172132.cf4d0a2d6acf2f6af96bb1c2@nifty.ne.jp> <20220801092349.860472b4da6f3a781eb3ffc4@nifty.ne.jp> <20220802131217.5ad7aa040f25a9b4e9266979@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220802131217.5ad7aa040f25a9b4e9266979@nifty.ne.jp> X-Provags-ID: V03:K1:OHhzs2HZry7qPh0uqWB8kQxXlnhBBOxETUsNvNoqJIuv0y8FcWk ZsHqL8tyLh5J1ISwSPRXsg1jL8Q/nJC4lBG2PlVDfZ544aBXj5f3oHgvrBhM/Un6+C4MgSe ERSXCXYka/Ot0UlppFpE0AJz80b0OjsGR3CuJM/3S8hkVkj39gN+PPamGH6iGol5GV5Dacn REhFJN2B3QYv1m4tYpTNQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:i46IfRbe4yY=:K0K+t7Ak6SPe4ygAxoBwX3 IbC+eR0NyDoT6/KGra5eCczn787Ad9NaaqrASZxeMlzAbCkz5RbAl0MoxARoKdvf7kw7PZA75 srZ58gOmogufcy/h7lL+qhyuBIon4Xx0RRRlKpJqJgypzmXWE64kXSBpwd2OT81NG8IXtikxV mWmHkvxXrAV5oYB0N1iBzEoj7h9yB8BDtkSQswpzZzolHBMINZO2SfKUtyLpUghjjqy2VAzoT n4a9/+r6/9IA7LRXpgsWvbkwyWxjPnn9TO/KxBfpKD4UtflqA0OQG7Ibqi2R41+4QFERURP87 4KDFVcDT7tyiVMqWqbVW6hYMJbCjxc9QyjorjCRR3asoNBcXX2h9fXYFZa3vk7uz5aGkz1S/1 DGFB2WCJxzVibBGLuojie0Cd0pLGA4kItsidRPHGMiUr/TXxpceNr2QYWr0AoEeXL/YFnPnqa WAqFYExxuIrK+3mWVuVV7xNaWgmTC/dChIlXkUVdW5Q9tbum5QlhHZqmM0oEMjysEqlMlo5tD xBT1RuKFglTA0QhYa6uP5S/AcoNWO/46mUCe42537UsCjyB1aWkfng1NQjov1D+eyqD28/w/B tNKYF8RqI9C2zbQazPVocYDZuRWmzTjFnOF6l3rhklZZM8PFM0qEPyKgwpWI8Fuda4S6DtYm4 TCRiQ4+GvyU9Qh6DPXHXI786+u7EcWSfS2g93/afa3hXi6S2HMUGHXW0tEJG+s5tv5x0SDRVE oQVKuALQlW5P4QvSQdn01oxL76W21Q4NyZaJiNx1KFS36PpwWbLU1UuaQ3o= X-Spam-Status: No, score=-101.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_NUMSUBJECT, RCVD_IN_MSPIKE_H2, SPF_FAIL, SPF_HELO_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin@cygwin.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: , X-List-Received-Date: Tue, 02 Aug 2022 08:19:48 -0000 On Aug 2 13:12, Takashi Yano wrote: > On Mon, 1 Aug 2022 21:14:52 -0400 > Ken Brown wrote: > > On 7/31/2022 8:23 PM, Takashi Yano wrote: > > > On Sun, 31 Jul 2022 17:21:32 +0900 > > > Takashi Yano wrote: > > >> On Sun, 31 Jul 2022 09:11:17 +0300 > > >> Dimax wrote: > > >>> $ ln -s /cygdrive/C/XOL/ work > > >>> $ ls -all work > > >>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/ > > >>> $ cd ~/work/ > > >>> -bash: cd: /home/Alex/work/: No such file or directory > > >>> > > >> Thanks for the report. This seems to happen only when > > >> the drive letter is uppercase. > > >> > > >> ln -s /cygdrive/c/XOL/ work > > >> works. > > >> > > >> Anyway, I think this is a problem of cygwin1.dll. > > >> [...] > > > I found the patch attached solves the issue. > > > > > > Corinna, WDYT? > > > > I'm not Corinna, but replacing oldpath by normpath doesn't seem like > > the right thing to do at the time of symlink creation. If I create > > a symlink under Cygwin, I expect the target to be used under Cygwin > > exactly as I enter it. Apart from the normalized mnt prefix, that's right. > Hmm, that's the point. > > > The internal replacement of the cygdrive prefix by /mnt for WSL > > compatibility is fine, as long as I never see it except under WSL. > > But since WSL doesn't recognize /mnt/, I > > don't think Cygwin should convert // > drive letter>. Users who want WSL interoperability just have to use > > lowercase drive letters. Yes, I agree. I'm surprised anyway that somebody is using uppercase drive letters voluntarily. > Then, what about the v2 patch attached? symlink_wsl is doing the right thing, as Ken points out. I think, the solution is not to change symlink creation but rather symlink evaluation. Locally I applied the below patch and fixed the issue: diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index ea695ed997b4..6b519d0bbe2d 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -2651,7 +2651,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp, } rp->ReparseDataLength = path_len + sizeof (DWORD); } - else if (islower (path_buf[drv_prefix_len + 1]) + else if (isalpha (path_buf[drv_prefix_len + 1]) && (path_len == drv_prefix_len + 2 || path_buf[drv_prefix_len + 2] == '/')) { This does not fix cases like /cygdrive/./c or something like that, but I wonder if we really have to handle them...? The idea was to convert /mnt into the cygdrive prefix only if this is a cygdrive path and not to touch /mnt if it's a user generated path. Therefore, the more effort the code makes to be clever, the higher chances are that an incorrect conversion takes place. Having said that, of course, we could change check_reparse_point_target to handle multiple slashes or dot path components, kind of like the below... ...but the point of discussion is, how much effort do we want to put into this? diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index ea695ed997b4..c7f743b3c7bf 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -2628,7 +2628,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp, char *path_buf = rpl->LxSymlinkReparseBuffer.PathBuffer; DWORD path_len = rpl->ReparseDataLength - sizeof (DWORD); bool full_path = false; - const size_t drv_prefix_len = strlen ("/mnt"); + size_t drv_prefix_len = 4; /* strlen ("/mnt") */ PBYTE utf16_ptr; PWCHAR utf16_buf; int utf16_bufsize; @@ -2651,15 +2651,30 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp, } rp->ReparseDataLength = path_len + sizeof (DWORD); } - else if (islower (path_buf[drv_prefix_len + 1]) + else + { + /* Skip multiple slashes and "." path components between + /mnt prefix and the drive letter. */ + while (true) + { + if (path_buf[drv_prefix_len + 1] == '/') + ++drv_prefix_len; + else if (path_buf[drv_prefix_len + 1] == '.' + && path_buf[drv_prefix_len + 2] == '/') + drv_prefix_len += 2; + else + break; + } + if (isalpha (path_buf[drv_prefix_len + 1]) && (path_len == drv_prefix_len + 2 || path_buf[drv_prefix_len + 2] == '/')) - { - /* Skip forward to the slash leading the drive letter. - That leaves room for adding the colon. */ - path_buf += drv_prefix_len; - path_len -= drv_prefix_len; - full_path = true; + { + /* Skip forward to the slash leading the drive letter. + That leaves room for adding the colon. */ + path_buf += drv_prefix_len; + path_len -= drv_prefix_len; + full_path = true; + } } } /* Compute buffer for path converted to UTF-16. */ > > I'm tempted to go even further and say that Cygwin shouldn't ever > > convert the cygdrive prefix to /mnt, on the grounds that users who > > care about WSL interoperability can simply use /mnt as their > > cygdrive prefix. But maybe that ship has sailed. In hindsight this might have been a step too far. I was trying to allow interoperability and reduce the number of problems based on different drive letter handling. And, well, this is the first time a user has a problem due to that :} The ship hasn't sailed entirely. We can revert this decision for 3.4 and just keep the /mnt conversion in check_reparse_point_target for backward compat. Or we just fix the problem at hand and otherwise keep the code as is...? Corinna