From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail231.csoft.net (mail231.csoft.net [96.47.74.235]) by sourceware.org (Postfix) with ESMTPS id 56A473851C2B for ; Sat, 15 May 2021 04:12:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 56A473851C2B Received: from mail231.csoft.net (localhost [127.0.0.1]) by mail231.csoft.net (Postfix) with ESMTP id 3983FCB50; Sat, 15 May 2021 00:12:49 -0400 (EDT) Received: from persephone (c-76-121-15-23.hsd1.wa.comcast.net [76.121.15.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jeremyd) by mail231.csoft.net (Postfix) with ESMTPSA id BF223CB4E; Sat, 15 May 2021 00:12:48 -0400 (EDT) Date: Fri, 14 May 2021 21:12:46 -0700 (Pacific Daylight Time) From: Jeremy Drake To: cygwin@cygwin.com cc: Orgad Shaneh Subject: realpath issue with native[strict] symlinks Message-ID: User-Agent: Alpine 2.22 (WNT 394 2020-01-19) X-X-Sender: jeremyd@mail231.csoft.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Sat, 15 May 2021 04:12:52 -0000 I apologize for not replying to the message properly, I am not subscribed and am copy-pasting from web archive. On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote: > The changes have a behavioral change, but I think this is for the > better: Virtual drives are not treated as drives anymore, but as > symlinks. Given they are just pointers to other drives or directories, > tha't much closer to reality. I. e., in case of my above virtual drive > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is > / only) is this: I am concerned about this behavior. The reason I was using subst to begin with was that some build tools encode the full path in their filenames, resulting in hitting MAX_PATH-related issues for not horribly long/deep paths. With this change, running a native Windows process (MinGW-w64) from a subst drive results in what it sees as the CWD being 'dereferenced' as though subst was not used, defeating the path-shortening purpose. For instance, using your example mapping: > $ ls -lG /cygdrive > total 16 > d---r-x---+ 1 TrustedInstaller 0 Apr 29 21:07 c > drwxr-xr-x 1 corinna 0 Dec 31 1979 e > lrwxrwxrwx 1 corinna 32 May 6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp Prior to these changes would show $ cd /cygdrive/t && cmd /c cd T:\ But after these changes would show $ cd /cygdrive/t && cmd /c cd C:\cygwin64\home\corinna\tmp This path could well be long enough to trigger build issues for certain MINGW-packages. Sorry to be a nuisance...