From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward102j.mail.yandex.net (forward102j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::102]) by sourceware.org (Postfix) with ESMTPS id 50BB538708DC for ; Fri, 12 Jun 2020 11:05:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 50BB538708DC Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=anrdaemon@yandex.ru Received: from mxback13g.mail.yandex.net (mxback13g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:92]) by forward102j.mail.yandex.net (Yandex) with ESMTP id 60FCFF2184B; Fri, 12 Jun 2020 14:05:02 +0300 (MSK) Received: from sas1-e20a8b944cac.qloud-c.yandex.net (sas1-e20a8b944cac.qloud-c.yandex.net [2a02:6b8:c14:6696:0:640:e20a:8b94]) by mxback13g.mail.yandex.net (mxback/Yandex) with ESMTP id Rv0DBTAaZF-520m21KR; Fri, 12 Jun 2020 14:05:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1591959902; bh=gdEVYtyEQ7hJHXDy++yrwGrlaiaapc7X5OZnKSc2Swg=; h=In-Reply-To:Subject:To:Reply-To:From:Message-ID:References:Date; b=J3NNAP8QoU7DmuiCjbcwBUYxiDL74VoMKMJlJAoDYpI6GD0DPHBhcUZv4sJrQ5yMN GP22awc5D8r8U95GyBX0gz1NlCCWdVhZQszXvvAarGi2ffL7OKoaqKLnbIM9zEk/q7 kmn7Y6ruIf8pWdcnVmQodtc61a7T3nbQkASHAuxI= Authentication-Results: mxback13g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-e20a8b944cac.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id gYRHjqpFtz-51WqFqtf; Fri, 12 Jun 2020 14:05:01 +0300 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client certificate not present) Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Fri, 12 Jun 2020 11:03:53 -0000 Date: Fri, 12 Jun 2020 14:03:53 +0300 From: Andrey Repin X-Mailer: The Bat! (v6.8.8) Home Reply-To: cygwin@cygwin.com X-Priority: 3 (Normal) Message-ID: <63059339.20200612140353@yandex.ru> To: Arthur Norman , cygwin@cygwin.com Subject: Re: symbolic links to /cygdrive/X/xxx with capital letter X In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_THEBAT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Fri, 12 Jun 2020 11:05:06 -0000 Greetings, Arthur Norman! > This running on Windows 10 1909 and cygwin has been updated to the latest > version. The effect was also visible on a freshly installed minimal cygwin > put on an almost fresh Windows 10 VM. > Cygwin these days seems to have a behaviour that confuses me regarding the > case of a disk name: >> ln -s "/cygdrive/c/Program Files" pf1 >> ln -s "/cygdrive/C/Program Files" pf2 >> ls -l pf* > lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files > lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37 pf2 -> /mnt/C/Program Files >> cygpath -ma ./pf1 > C:/cygwin64/home/acn1/pf1 > You see from the above that when I use cygpath to convert from a cygwin > name the drive letter C: is returned in upper case. When that ends up > after "/cygdrive" the path behaves as I expect almost everywhere by is > treated specially for symbolic links. This seems to be a relatively new > behaviour and it bit me! > [Use-case: I wanted to convert cygwin paths to be "very absolute" so that > eg my home directory is not rendered as /home/acn1 but as > /cygdrive/c/cygwin64/home/acn1, cygpath is not meant to replace realpath/readlink. And you've got exactly what you asked for. -m returns Windows path with forward slashes. -a returns absolute path. > so I had a few lines of shell script to > achieve that. I was building a package and I build both a cygwin32 and a > cygwin64 version, so the "very absolute" paths are portable between the > two worlds, both of which were important when I first set this up. Things > recently broke and on investigation it was because somewhere deep in > build scripts links to /mnt/C/... had been set up and were not usable. I > can of course work round the issue but being confident I have spotted all > cases causes me work!] readlink -e ./pf1 man readlink -- With best regards, Andrey Repin Friday, June 12, 2020 14:01:51 Sorry for my terrible english...