From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-041.btinternet.com (mailomta7-re.btinternet.com [213.120.69.100]) by sourceware.org (Postfix) with ESMTPS id 014EC3858C60 for ; Mon, 10 Jan 2022 15:39:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 014EC3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-041.btinternet.com with ESMTP id <20220110153916.OZLC24157.re-prd-fep-041.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net>; Mon, 10 Jan 2022 15:39:16 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC310013AF3 X-Originating-IP: [81.129.146.209] X-OWM-Source-IP: 81.129.146.209 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvuddrudehuddgheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeehudeuveeujeeujeegueefhedttdekvedtudeileefteetfeefjeejudekfefggfenucffohhmrghinheptgihghifihhnrdgtohhmnecukfhppeekuddruddvledrudegiedrvddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtfegnpdhinhgvthepkedurdduvdelrddugeeirddvtdelpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdprhgtphhtthhopeffrghvihgurdetlhhlshhophhpsegtlhdrtggrmhdrrggtrdhukhdprhgtphhtthhopegthihgfihinhestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (81.129.146.209) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8CC310013AF3; Mon, 10 Jan 2022 15:39:15 +0000 Message-ID: <6d1a8071-76f7-b634-b4ce-07ce6c18a8d9@dronecode.org.uk> Date: Mon, 10 Jan 2022 15:39:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Cygwin setup writing incorrect symlinks for native Content-Language: en-GB To: David Allsopp , The Cygwin Mailing List References: <000201d802ea$e13fd790$a3bf86b0$@cl.cam.ac.uk> <53ca12d5a17d43089bc38ef67e4cc858@metastack.com> <1afc3b10-e19d-5b97-4ca7-b143f3262e67@dronecode.org.uk> <1a271142acbc4e2188fc3b6981fa03e0@metastack.com> From: Jon Turney In-Reply-To: <1a271142acbc4e2188fc3b6981fa03e0@metastack.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.6 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_EXEURI, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no 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@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: Mon, 10 Jan 2022 15:39:18 -0000 On 09/01/2022 09:35, David Allsopp wrote: > Jon Turney wrote: >> On 06/01/2022 16:45, David Allsopp wrote: >>> Jon Turney wrote: >>>> On 06/01/2022 10:46, David Allsopp wrote: >>>>> Running Cygwin setup 2.912 with --symlink-type native (or >>>>> CYGWIN=winsymlinks:native) is not correctly translating all symlinks. >>>>> A default install has these faulty ones: >>>>> >>>>> /etc/pki/tls/cert.pem -> >>>>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem >>>>> /etc/pki/tls/certs/ca-bundle.crt -> >>>>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem >>>>> /etc/pki/tls/certs/ca-bundle.trust.crt -> >>>>> \??\/etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt >>>>> /etc/ssl/certs -> \??\/etc\pki\tls\certs /lib/security/cacerts -> >>>>> \??\/etc\pki\ca-trust\extracted\java\cacerts >>>>> /usr/share/doc/groff-1.22.4/pdf/mom-pdf.pdf -> >>>>> \??\/usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf >>>> >>>> [...] >> >> Thanks for testing. It seems I still didn't have this quite right and >> these symlinks just happened to work for cygwin, but not native tools. >> >> Please try >> >> https://cygwin.com/setup/setup-2.914.x86_64.exe >> https://cygwin.com/setup/setup-2.914.x86.exe > > I'm afraid that's just changed the \??\ to \\?\ on those symlinks. Well, that has the advantage of being correct :) (since it's the 'Win32 File Namespace' prefix, which CreateSymbolicLinkW() is documented to accept for the target filename, and is required when that exceeds MAX_PATH (260) characters) In my (brief) testing, e.g. the CMD builtin 'type' is able to open symlinks of this form. However, it seems there are some parts of Windows (e.g. DIR, File Explorer), which don't handle symlinks like that well. So, I've copied the behaviour of the cygwin DLL, which avoids using that prefix if the target is less than MAX_PATH characters. This seem to work better in those cases with typical paths (but I'd claim we're just working around a bug in Windows here, as things will still be broken if the cygwin root is a path long enough that we can't do that). Please try: https://cygwin.com/setup/setup-2.915.x86_64.exe https://cygwin.com/setup/setup-2.915.x86.exe