X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D2F43854825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1602687410; bh=jGKU3xDo/eBQgjXdeaZcboh/0keTalIJoktXkPR09Ms=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=LYRXvcMkQkFeC+W88kHOtK5JOY0Yf8qbTAkMuQMraNPjfY9oawFXC2LnXkobgBTvv HKUQMV1fPXDBfb0LPnnSGlIk1iyVPdrb0Fn1BjlSRkpGd0gteR6CqBn8fM0RFedDz8 nH1zeuik/NItRCq2/TBG6wRIyk5LgP9jYk/z3SpE= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FFB23857C5F To: "'cygwin'" Subject: Strange behaviour with winsymlinks:native Date: Wed, 14 Oct 2020 15:56:47 +0100 Message-ID: <001001d6a23a$3d5ebc70$b81c3550$@cl.cam.ac.uk> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdaiOX566BkQk787SuqiWyZWu5HS8w== Content-Language: en-gb X-Scanned-By: MIMEDefang 2.65 on 62.31.23.242 X-Server-Quench: 799b9aa4-0e2d-11eb-8a6b-8434971169dc X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZ5RRob BmUtCCtbTh09DhZI RxQKKE1TKxwUVhJa I0lFL1x7O0wTWlBf HTVUBhpVVEIOCidq aQpTbRVcZ0BLWQ9u VAZPQExRFRtqAgID AhwBUBxtdktGcQsF IB4dPXBbWkR8cAh/ Qk9TW2oPbDVpOTEb TUANdVdJcQIfLAJN O1YtSXsJYmEOYXth QV4/NCYKIS9WLitY CgsALVsMQEEWBHYj RgwCVSouG1YUQiEy KR89eFgVAEcPPy0A X-Authentic-SMTP: 61633634383431.1024:7600 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 62.31.23.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, MAY_BE_FORGED, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, 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 AT cygwin DOT com X-Mailman-Version: 2.1.29 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: David Allsopp via Cygwin Reply-To: David Allsopp Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Cygwin" I've been doing some working around the problems with Cygwin 3.1.5+ WSL junction points in Docker and found three unexpected pieces of behaviour with CYGWIN=winsymlinks:native In all cases, these work as expected with the default symlink behaviour (i.e. CYGWIN unset or without a winsymlinks option). 1. Relative paths get unnecessarily resolved mkdir -p foo/bar cd foo/bar touch baz CYGWIN='winsymlinks:native' ln -s ../bar/baz link readlink link Result is baz, not ../bar/baz 2a. Links in the magic mount directories (/usr/bin and /usr/lib) get extra bits added (source is a default mount): cd /usr/lib CYGWIN='winsymlinks:native' ln -s ../share/terminfo terminfo2 readlink terminfo2 Result is ../usr/share/terminfo, which makes it valid from /lib (the "real" directory) but not in the virtual one 2b. Same but where target is a default mount cd /usr/libexec/p11-kit CYGWIN='winsymlinks:native' ln -s ../../bin/update-ca-trust trust-extract-compat2 readlink trust-extract-compat2 Result is ../../../bin/update-ca-trust, again it seems to be computing an extra level back to the "real" lib directory Are these behaviours expected? I can create those symbolic links manually with mklink with no problem, so I'm wondering if it's an outright bug or an unexpected consequence of something else. Thanks! David -- 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