From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97120 invoked by alias); 3 Mar 2020 13:17:43 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 97104 invoked by uid 89); 3 Mar 2020 13:17:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:2a02, H*RU:2a02, H*r:2a02, Emrich X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 13:17:41 +0000 Received: from addc1.ad.local.emrich-ebersheim.de ([24.134.13.209]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MsYzD-1jOIzx3acV-00tzMx; Tue, 03 Mar 2020 14:17:38 +0100 Received: from localhost (localhost [127.0.0.1]) by addc1.ad.local.emrich-ebersheim.de (Postfix) with ESMTP id 5EA5F282853; Tue, 3 Mar 2020 14:17:38 +0100 (CET) Received: from addc1.ad.local.emrich-ebersheim.de ([127.0.0.1]) by localhost (addc1.ad.local.emrich-ebersheim.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYfyWAJHNuHG; Tue, 3 Mar 2020 14:17:37 +0100 (CET) Received: from [IPv6:2a02:8106:22a:130d:8c81:a787:abfc:8c10] (unknown [IPv6:2a02:8106:22a:130d:8c81:a787:abfc:8c10]) by addc1.ad.local.emrich-ebersheim.de (Postfix) with ESMTPS id 9C1E928284B; Tue, 3 Mar 2020 14:17:37 +0100 (CET) Subject: Re: Change in logical link behaviour To: cygwin@cygwin.com References: <30792264-c452-7ea2-c83f-f368322387ea@emrich-ebersheim.de> <20200302164851.GS4045@calimero.vinschen.de> Cc: corinna-cygwin@cygwin.com From: Rainer Emrich Message-ID: Date: Tue, 03 Mar 2020 13:17:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200302164851.GS4045@calimero.vinschen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi" X-SW-Source: 2020-03/txt/msg00042.txt --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi Content-Type: multipart/mixed; boundary="D016zOa0k59sSUWqEC8L8RYLyVBa4npGd" --D016zOa0k59sSUWqEC8L8RYLyVBa4npGd Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable Content-length: 3127 Dear Corinna, Am 02.03.2020 um 17:48 schrieb Corinna Vinschen: > On Feb 29 14:10, Rainer Emrich wrote: >> I try to reliably determine if native Windows symlink are working for a >> current cygwin environment in a shell script. >> >> Therefor I used a powershell snipped: >> >> mkdir asdfgh >> ln -s asdfgh/ asdfgh-1 >> powershell "& {Get-Item -Path asdfgh-1 | Select-Object}" >> >> On cygwin 3.0.7 the output is as follows: >> >> >> Directory: D:\cygwin\home\rainer\temp >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d----l 29.02.2020 13:58 asdfgh-1 >> >> On cygwin 3.1.4 I get: >> >> >> Directory: D:\cygwin\home\rainer\temp >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d---- 29.02.2020 13:58 asdfgh-1 >> >> So now there is no indication that this is a link. Is this new behaviour >> intended or a bug? >> >> I did not try on Windows 10, I'm still on windows 7. >> >> Rainer >> >=20 > I can't reproduce this behaviour. Keep in mind that, by default, you > *have to* run in an elevated shell to be able to create native NTFS > symlinks, *and* you *have to* set the environment variable CYGWIN(*) to > contain "winsymlinks:native" or "winsymlinks:nativestrict". The latter > is nice for testing, it refuses to fall back silently to the default > Cygwin-only symlinks but fails instead if it can't create a native > NTFS symlink. I know all the implications. I have to test in an unknown cygwin environment if it is possible to set native symlinks. >=20 > So, on Windows 7 in an elevated shell: >=20 > # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated > elevated > # uname -a > CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin > # mkdir qwe > # cd qwe > # export CYGWIN=3D"winsymlinks:nativestrict" > # touch foo > # ln -s foo bar > # cmd /c dir /a > Volume in drive C has no label. > Volume Serial Number is A8E0-A24E >=20 > Directory of C:\cygwin64\home\corinna\qwe >=20 > 2020-03-02 17:31 . > 2020-03-02 17:31 .. > 2020-03-02 17:31 bar [foo] > 2020-03-02 17:31 0 foo > 2 File(s) 0 bytes > 2 Dir(s) 7.907.352.576 bytes free >=20 Yes, this is the same for me, but if you use the powershell # powershell "& {Get-Item -Path bar | Select-Object}" on cygwin 3.0.7 you get Directory: D:\cygwin\home\rainer\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---l 03.03.2020 14:09 0 bar and on cygwin 3.1.4 you get Directory: D:\cygwin\home\rainer\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 03.03.2020 14:09 0 bar The only difference is the used cygwin version. So, I don't understand what has changed. Cheers Rainer --D016zOa0k59sSUWqEC8L8RYLyVBa4npGd-- --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEQq4BT9NfW50eSlCTkX2ILOIqatIFAl5eWPEACgkQkX2ILOIq atKC8hAAmL1Coh041WlHnxs0ulbdZnVuAuOU7hYK9G5URNJfOr36in2axDLLbkk9 4tIu2yGFVam6ViYiPPXujAYZIL81Mg/ensQjXWlOzGdiHIe5PL9dl8I6Nhc0iuVA TkgPZZfPzIcxl4R5vJ99jm2qFrK6Bc6pH0SSh5dAT9NppOE/XYjXfbkovWEL3HTv a0kd3XHOzBxMo0256Ms2FhdLkbA9mZrTAK1bRVdvLtOnVzCY6wJ+i5ZM0BlVp0vM PUWlJ7nFR0HRSOiS6vmIVWKWPndfv5DI5Haxb49cq5ChKBcOrZqDuoRzfWox3Sr9 1iCSuAkMA/3nxuMFPC6jUYln4izAJHUQrAEKXhla7VTqsc4D3vcWdRlEzvJUzVyr Djo3bP2xq2nr1m63FaZd1FJf6IGQwrAnsjFrjvMW6SEHw9HpdGz4S5XzsfNsbCtR aaFoMaFSUDj6Y70KGKlKs8pWeMguWMsPu5GeO3mirDnN+hrAeNRoz0ipjD41kRgf m7D6llt3L3SVlxzXiAUX86weX/2ASVMgDQJdvxvubd3CnjKGJ5YCS/a619VEV9m4 0sIypLfDOXI31qEPRLtmbcUVTO3K0j53/BiS9WRQCPOO86XbgQPkwLMvQGXaVW3D H2WNZckvkhOyTnqM3XmsGkF1eUsTOy6P/3un5BVFdGbEzVPhQNI= =ZDZP -----END PGP SIGNATURE----- --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97128 invoked by alias); 3 Mar 2020 13:17:43 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 97109 invoked by uid 9078); 3 Mar 2020 13:17:43 -0000 Received: (qmail 97104 invoked by uid 89); 3 Mar 2020 13:17:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:2a02, H*RU:2a02, H*r:2a02, Emrich X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 13:17:41 +0000 Received: from addc1.ad.local.emrich-ebersheim.de ([24.134.13.209]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MsYzD-1jOIzx3acV-00tzMx; Tue, 03 Mar 2020 14:17:38 +0100 Received: from localhost (localhost [127.0.0.1]) by addc1.ad.local.emrich-ebersheim.de (Postfix) with ESMTP id 5EA5F282853; Tue, 3 Mar 2020 14:17:38 +0100 (CET) Received: from addc1.ad.local.emrich-ebersheim.de ([127.0.0.1]) by localhost (addc1.ad.local.emrich-ebersheim.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYfyWAJHNuHG; Tue, 3 Mar 2020 14:17:37 +0100 (CET) Received: from [IPv6:2a02:8106:22a:130d:8c81:a787:abfc:8c10] (unknown [IPv6:2a02:8106:22a:130d:8c81:a787:abfc:8c10]) by addc1.ad.local.emrich-ebersheim.de (Postfix) with ESMTPS id 9C1E928284B; Tue, 3 Mar 2020 14:17:37 +0100 (CET) Subject: Re: Change in logical link behaviour To: cygwin@cygwin.com References: <30792264-c452-7ea2-c83f-f368322387ea@emrich-ebersheim.de> <20200302164851.GS4045@calimero.vinschen.de> Cc: corinna-cygwin@cygwin.com From: Rainer Emrich Message-ID: Date: Tue, 03 Mar 2020 13:39:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200302164851.GS4045@calimero.vinschen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi" X-SW-Source: 2020-03/txt/msg00043.txt Message-ID: <20200303133900.kBPs10PUJaXGV_upK9VKZfCrXceTcEaVW-iWH7TcQXY@z> --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi Content-Type: multipart/mixed; boundary="D016zOa0k59sSUWqEC8L8RYLyVBa4npGd" --D016zOa0k59sSUWqEC8L8RYLyVBa4npGd Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable Content-length: 3127 Dear Corinna, Am 02.03.2020 um 17:48 schrieb Corinna Vinschen: > On Feb 29 14:10, Rainer Emrich wrote: >> I try to reliably determine if native Windows symlink are working for a >> current cygwin environment in a shell script. >> >> Therefor I used a powershell snipped: >> >> mkdir asdfgh >> ln -s asdfgh/ asdfgh-1 >> powershell "& {Get-Item -Path asdfgh-1 | Select-Object}" >> >> On cygwin 3.0.7 the output is as follows: >> >> >> Directory: D:\cygwin\home\rainer\temp >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d----l 29.02.2020 13:58 asdfgh-1 >> >> On cygwin 3.1.4 I get: >> >> >> Directory: D:\cygwin\home\rainer\temp >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d---- 29.02.2020 13:58 asdfgh-1 >> >> So now there is no indication that this is a link. Is this new behaviour >> intended or a bug? >> >> I did not try on Windows 10, I'm still on windows 7. >> >> Rainer >> >=20 > I can't reproduce this behaviour. Keep in mind that, by default, you > *have to* run in an elevated shell to be able to create native NTFS > symlinks, *and* you *have to* set the environment variable CYGWIN(*) to > contain "winsymlinks:native" or "winsymlinks:nativestrict". The latter > is nice for testing, it refuses to fall back silently to the default > Cygwin-only symlinks but fails instead if it can't create a native > NTFS symlink. I know all the implications. I have to test in an unknown cygwin environment if it is possible to set native symlinks. >=20 > So, on Windows 7 in an elevated shell: >=20 > # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated > elevated > # uname -a > CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin > # mkdir qwe > # cd qwe > # export CYGWIN=3D"winsymlinks:nativestrict" > # touch foo > # ln -s foo bar > # cmd /c dir /a > Volume in drive C has no label. > Volume Serial Number is A8E0-A24E >=20 > Directory of C:\cygwin64\home\corinna\qwe >=20 > 2020-03-02 17:31 . > 2020-03-02 17:31 .. > 2020-03-02 17:31 bar [foo] > 2020-03-02 17:31 0 foo > 2 File(s) 0 bytes > 2 Dir(s) 7.907.352.576 bytes free >=20 Yes, this is the same for me, but if you use the powershell # powershell "& {Get-Item -Path bar | Select-Object}" on cygwin 3.0.7 you get Directory: D:\cygwin\home\rainer\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---l 03.03.2020 14:09 0 bar and on cygwin 3.1.4 you get Directory: D:\cygwin\home\rainer\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 03.03.2020 14:09 0 bar The only difference is the used cygwin version. So, I don't understand what has changed. Cheers Rainer --D016zOa0k59sSUWqEC8L8RYLyVBa4npGd-- --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEQq4BT9NfW50eSlCTkX2ILOIqatIFAl5eWPEACgkQkX2ILOIq atKC8hAAmL1Coh041WlHnxs0ulbdZnVuAuOU7hYK9G5URNJfOr36in2axDLLbkk9 4tIu2yGFVam6ViYiPPXujAYZIL81Mg/ensQjXWlOzGdiHIe5PL9dl8I6Nhc0iuVA TkgPZZfPzIcxl4R5vJ99jm2qFrK6Bc6pH0SSh5dAT9NppOE/XYjXfbkovWEL3HTv a0kd3XHOzBxMo0256Ms2FhdLkbA9mZrTAK1bRVdvLtOnVzCY6wJ+i5ZM0BlVp0vM PUWlJ7nFR0HRSOiS6vmIVWKWPndfv5DI5Haxb49cq5ChKBcOrZqDuoRzfWox3Sr9 1iCSuAkMA/3nxuMFPC6jUYln4izAJHUQrAEKXhla7VTqsc4D3vcWdRlEzvJUzVyr Djo3bP2xq2nr1m63FaZd1FJf6IGQwrAnsjFrjvMW6SEHw9HpdGz4S5XzsfNsbCtR aaFoMaFSUDj6Y70KGKlKs8pWeMguWMsPu5GeO3mirDnN+hrAeNRoz0ipjD41kRgf m7D6llt3L3SVlxzXiAUX86weX/2ASVMgDQJdvxvubd3CnjKGJ5YCS/a619VEV9m4 0sIypLfDOXI31qEPRLtmbcUVTO3K0j53/BiS9WRQCPOO86XbgQPkwLMvQGXaVW3D H2WNZckvkhOyTnqM3XmsGkF1eUsTOy6P/3un5BVFdGbEzVPhQNI= =ZDZP -----END PGP SIGNATURE----- --fARJM0sCJ8U6nIxbYyF9ecOFlQ6jiqUFi--