Change in logical link behaviour

Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 934 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Andrey Repin]

Greetings, Rainer Emrich!

> 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.

I get the same behavior is not using Cygwin to create the link at all, this is
probably a change in how Cygwin interprets symlinks.


-- 
With best regards,
Andrey Repin
Sunday, March 1, 2020 4:51:46

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 1407 bytes --]

Hi Andrey,

Am 01.03.2020 um 02:52 schrieb Andrey Repin:
>> 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.
> 
> I get the same behavior is not using Cygwin to create the link at all, this is
> probably a change in how Cygwin interprets symlinks.
I don't know what's going on here. The only difference is the cygwin
version. So, the different behaviour is caused by cygwin while creating
the link, for sure!

Somebody any idea?

Rainer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]

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
> 

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.

So, on Windows 7 in an elevated shell:

  # 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="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

   Directory of C:\cygwin64\home\corinna\qwe

  2020-03-02  17:31    <DIR>          .
  2020-03-02  17:31    <DIR>          ..
  2020-03-02  17:31    <SYMLINK>      bar [foo]
  2020-03-02  17:31                 0 foo
                 2 File(s)              0 bytes
		 2 Dir(s)   7.907.352.576 bytes free

In a non-elevated shell:

  $ id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
  non-elevated
  $ uname -r
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  $ cd qwe
  $ export CYGWIN="winsymlinks:nativestrict"
  $ rm bar
  $ ln -s foo bar
  ln: failed to create symbolic link 'bar': Operation not permitted
  $ export CYGWIN="winsymlinks:native"  # !!!
  $ ln -s foo bar
  $ cmd /c dir /a
   Volume in drive C has no label.
   Volume Serial Number is A8E0-A24E

   Directory of C:\cygwin64\home\corinna\qwe

  2020-03-02  17:31    <DIR>          .
  2020-03-02  17:31    <DIR>          ..
  2020-03-02  17:38                20 bar
  2020-03-02  17:31                 0 foo
                 2 File(s)             20 bytes
		 2 Dir(s)   7.907.352.576 bytes free

The symlink created last is a Cygwin-only symlink (special file
with SYSTEM attribute), not a native symlink.


Corinna

(*) https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
(*) https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks


-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 3224 bytes --]

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
>>
> 
> 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.

> 
> So, on Windows 7 in an elevated shell:
> 
>   # 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="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
> 
>    Directory of C:\cygwin64\home\corinna\qwe
> 
>   2020-03-02  17:31    <DIR>          .
>   2020-03-02  17:31    <DIR>          ..
>   2020-03-02  17:31    <SYMLINK>      bar [foo]
>   2020-03-02  17:31                 0 foo
>                  2 File(s)              0 bytes
> 		 2 Dir(s)   7.907.352.576 bytes free
> 
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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 3224 bytes --]

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
>>
> 
> 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.

> 
> So, on Windows 7 in an elevated shell:
> 
>   # 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="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
> 
>    Directory of C:\cygwin64\home\corinna\qwe
> 
>   2020-03-02  17:31    <DIR>          .
>   2020-03-02  17:31    <DIR>          ..
>   2020-03-02  17:31    <SYMLINK>      bar [foo]
>   2020-03-02  17:31                 0 foo
>                  2 File(s)              0 bytes
> 		 2 Dir(s)   7.907.352.576 bytes free
> 
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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5080 bytes --]

On Mar  3 14:17, Rainer Emrich wrote:
> 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.
> >> [...]
> >> 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.
> > 
> > I can't reproduce this behaviour.  Keep in mind that, [bla]
> I know all the implications. I have to test in an unknown cygwin
> environment if it is possible to set native symlinks.
> > 
> > So, on Windows 7 in an elevated shell:
> > 
> >   # 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="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
> > 
> >    Directory of C:\cygwin64\home\corinna\qwe
> > 
> >   2020-03-02  17:31    <DIR>          .
> >   2020-03-02  17:31    <DIR>          ..
> >   2020-03-02  17:31    <SYMLINK>      bar [foo]
> >   2020-03-02  17:31                 0 foo
> >                  2 File(s)              0 bytes
> > 		 2 Dir(s)   7.907.352.576 bytes free
> > 
> 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.

Nothing has changed in terms of symlink handling.  Are you saying that
`cmd /c dir /a' shows

  2020-03-03  14:21    <SYMLINK>      bar [foo]

but powershell shows

  -a---        03.03.2020     14:21              0 bar

for the same file?  That would be most puzzeling but certainly outside
of Cygwin's control.

So I created a symlink again on W7 with Cygwin 3.1.4 and `export
CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
(which I usually don't touch) and I see

  # uname -a
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  # setenv CYGWIN winsymlinks:nativestrict
  # ln -s foo bar
  # cmd /c dir /a bar
   Volume in drive C has no label.
   Volume Serial Number is A8E0-A24E

   Directory of C:\cygwin64\home\corinna\qwe

  03.03.2020  14:30    <SYMLINK>      bar [foo]
		 1 File(s)              0 bytes
		 0 Dir(s)   7.929.241.600 bytes free
  # powershell "& {Get-Item -Path bar | Select-Object}"


      Directory: C:\cygwin64\home\corinna\qwe


  Mode                LastWriteTime     Length Name
  ----                -------------     ------ ----
  -a---        03.03.2020     14:30          0 bar

Aha!  So powershell does not show the 'l'.

Let's try the same on Windows 10:

  # uname.ORIG -a
  CYGWIN_NT-10.0 vmbert10 3.1.5(0.340/5/3) 2020-03-02 18:46 x86_64 Cygwin
  # setenv CYGWIN winsymlinks:nativestrict
  # ln -s foo bar
  # cmd /c dir /a bar
   Volume in drive C has no label.
   Volume Serial Number is C65C-2A36

   Directory of C:\cygwin64\home\corinna\tmp

  2020-03-03  14:33    <SYMLINK>      bar [foo]
		 1 File(s)              0 bytes
		 0 Dir(s)  23,112,925,184 bytes free
  # powershell "& {Get-Item -Path bar | Select-Object}"


      Directory: C:\cygwin64\home\corinna\tmp


  Mode                LastWriteTime         Length Name
  ----                -------------         ------ ----
  -a---l       2020-03-03     14:33              0 bar

Aha!  powershell shows the 'l'.  Also, notice how the number of
mode bits seem to be only 5 on Windows 7:

  -a---
  ^^^^^
  12345

but *6* on Windows 10:

  -a---l
  ^^^^^^
  123456

On Windows 10 it shows 6 mode bits for non-symlinks as well, so the 'l'
mode is not just missing on Windows 7 in this specific case, but a
generic difference.  From my POV, this is just a shortcoming of W7
powershell.  Keep in mind that the output of powershell has nothing to
do with Cygwin itself.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 4177 bytes --]

Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> On Mar  3 14:17, Rainer Emrich wrote:
>> 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.
>>>> [...]
>>>> 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.
>>>
>>> I can't reproduce this behaviour.  Keep in mind that, [bla]
>> I know all the implications. I have to test in an unknown cygwin
>> environment if it is possible to set native symlinks.
>>>
>>> So, on Windows 7 in an elevated shell:
>>>
>>>   # 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="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
>>>
>>>    Directory of C:\cygwin64\home\corinna\qwe
>>>
>>>   2020-03-02  17:31    <DIR>          .
>>>   2020-03-02  17:31    <DIR>          ..
>>>   2020-03-02  17:31    <SYMLINK>      bar [foo]
>>>   2020-03-02  17:31                 0 foo
>>>                  2 File(s)              0 bytes
>>> 		 2 Dir(s)   7.907.352.576 bytes free
>>>
>> 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.
> 
> Nothing has changed in terms of symlink handling.  Are you saying that
> `cmd /c dir /a' shows
> 
>   2020-03-03  14:21    <SYMLINK>      bar [foo]
> 
> but powershell shows
> 
>   -a---        03.03.2020     14:21              0 bar
> 
> for the same file?  That would be most puzzeling but certainly outside
> of Cygwin's control.
> 
> So I created a symlink again on W7 with Cygwin 3.1.4 and `export
> CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
> (which I usually don't touch) and I see
> 
>   # uname -a
>   CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
>   # setenv CYGWIN winsymlinks:nativestrict
>   # ln -s foo bar
>   # cmd /c dir /a bar
>    Volume in drive C has no label.
>    Volume Serial Number is A8E0-A24E
> 
>    Directory of C:\cygwin64\home\corinna\qwe
> 
>   03.03.2020  14:30    <SYMLINK>      bar [foo]
> 		 1 File(s)              0 bytes
> 		 0 Dir(s)   7.929.241.600 bytes free
>   # powershell "& {Get-Item -Path bar | Select-Object}"
> 
> 
>       Directory: C:\cygwin64\home\corinna\qwe
> 
> 
>   Mode                LastWriteTime     Length Name
>   ----                -------------     ------ ----
>   -a---        03.03.2020     14:30          0 bar
> 
> Aha!  So powershell does not show the 'l'.
The most important thing is the difference between cygwin 3.0.7 and
cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
only difference is the cygwin version.

Rainer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 4177 bytes --]

Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> On Mar  3 14:17, Rainer Emrich wrote:
>> 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.
>>>> [...]
>>>> 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.
>>>
>>> I can't reproduce this behaviour.  Keep in mind that, [bla]
>> I know all the implications. I have to test in an unknown cygwin
>> environment if it is possible to set native symlinks.
>>>
>>> So, on Windows 7 in an elevated shell:
>>>
>>>   # 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="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
>>>
>>>    Directory of C:\cygwin64\home\corinna\qwe
>>>
>>>   2020-03-02  17:31    <DIR>          .
>>>   2020-03-02  17:31    <DIR>          ..
>>>   2020-03-02  17:31    <SYMLINK>      bar [foo]
>>>   2020-03-02  17:31                 0 foo
>>>                  2 File(s)              0 bytes
>>> 		 2 Dir(s)   7.907.352.576 bytes free
>>>
>> 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.
> 
> Nothing has changed in terms of symlink handling.  Are you saying that
> `cmd /c dir /a' shows
> 
>   2020-03-03  14:21    <SYMLINK>      bar [foo]
> 
> but powershell shows
> 
>   -a---        03.03.2020     14:21              0 bar
> 
> for the same file?  That would be most puzzeling but certainly outside
> of Cygwin's control.
> 
> So I created a symlink again on W7 with Cygwin 3.1.4 and `export
> CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
> (which I usually don't touch) and I see
> 
>   # uname -a
>   CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
>   # setenv CYGWIN winsymlinks:nativestrict
>   # ln -s foo bar
>   # cmd /c dir /a bar
>    Volume in drive C has no label.
>    Volume Serial Number is A8E0-A24E
> 
>    Directory of C:\cygwin64\home\corinna\qwe
> 
>   03.03.2020  14:30    <SYMLINK>      bar [foo]
> 		 1 File(s)              0 bytes
> 		 0 Dir(s)   7.929.241.600 bytes free
>   # powershell "& {Get-Item -Path bar | Select-Object}"
> 
> 
>       Directory: C:\cygwin64\home\corinna\qwe
> 
> 
>   Mode                LastWriteTime     Length Name
>   ----                -------------     ------ ----
>   -a---        03.03.2020     14:30          0 bar
> 
> Aha!  So powershell does not show the 'l'.
The most important thing is the difference between cygwin 3.0.7 and
cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
only difference is the cygwin version.

Rainer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Mar  3 15:19, Rainer Emrich wrote:
> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> > Aha!  So powershell does not show the 'l'.
> The most important thing is the difference between cygwin 3.0.7 and
> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
> only difference is the cygwin version.

I may believe you, but believe me that Cygwin has no influence on
what powershell shows.  See the output of cmd /c dir /a.  The file
is a native symlink.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Mar  3 15:31, Corinna Vinschen wrote:
> On Mar  3 15:19, Rainer Emrich wrote:
> > Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> > > Aha!  So powershell does not show the 'l'.
> > The most important thing is the difference between cygwin 3.0.7 and
> > cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
> > powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
> > only difference is the cygwin version.
> 
> I may believe you, but believe me that Cygwin has no influence on
> what powershell shows.  See the output of cmd /c dir /a.  The file
> is a native symlink.

...and for kicks I just tried this on W7 under Cygwin 3.0.7.  The output
is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html

No 'l' mode flag, no 6th column in the mode output:

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        03.03.2020     16:47          0 bar


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]

Am 03.03.2020 um 16:49 schrieb Corinna Vinschen:
> On Mar  3 15:31, Corinna Vinschen wrote:
>> On Mar  3 15:19, Rainer Emrich wrote:
>>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
>>>> Aha!  So powershell does not show the 'l'.
>>> The most important thing is the difference between cygwin 3.0.7 and
>>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
>>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
>>> only difference is the cygwin version.
>>
>> I may believe you, but believe me that Cygwin has no influence on
>> what powershell shows.  See the output of cmd /c dir /a.  The file
>> is a native symlink.
> 
> ...and for kicks I just tried this on W7 under Cygwin 3.0.7.  The output
> is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html
> 
> No 'l' mode flag, no 6th column in the mode output:
> 
> Mode                LastWriteTime     Length Name
> ----                -------------     ------ ----
> -a---        03.03.2020     16:47          0 bar
> 
> 
For me it's different. That's realy strange.

Ok, so I can't rely on powershell here. Is there a recommended procedure
for what I try in a script?

Check if the current cygwin environment is able to create native symlinks.

Thanks

Rainer




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]

Am 03.03.2020 um 16:49 schrieb Corinna Vinschen:
> On Mar  3 15:31, Corinna Vinschen wrote:
>> On Mar  3 15:19, Rainer Emrich wrote:
>>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
>>>> Aha!  So powershell does not show the 'l'.
>>> The most important thing is the difference between cygwin 3.0.7 and
>>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
>>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
>>> only difference is the cygwin version.
>>
>> I may believe you, but believe me that Cygwin has no influence on
>> what powershell shows.  See the output of cmd /c dir /a.  The file
>> is a native symlink.
> 
> ...and for kicks I just tried this on W7 under Cygwin 3.0.7.  The output
> is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html
> 
> No 'l' mode flag, no 6th column in the mode output:
> 
> Mode                LastWriteTime     Length Name
> ----                -------------     ------ ----
> -a---        03.03.2020     16:47          0 bar
> 
> 
For me it's different. That's realy strange.

Ok, so I can't rely on powershell here. Is there a recommended procedure
for what I try in a script?

Check if the current cygwin environment is able to create native symlinks.

Thanks

Rainer




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Mar  3 17:05, Rainer Emrich wrote:
> Am 03.03.2020 um 16:49 schrieb Corinna Vinschen:
> > On Mar  3 15:31, Corinna Vinschen wrote:
> >> On Mar  3 15:19, Rainer Emrich wrote:
> >>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> >>>> Aha!  So powershell does not show the 'l'.
> >>> The most important thing is the difference between cygwin 3.0.7 and
> >>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
> >>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
> >>> only difference is the cygwin version.
> >>
> >> I may believe you, but believe me that Cygwin has no influence on
> >> what powershell shows.  See the output of cmd /c dir /a.  The file
> >> is a native symlink.
> > 
> > ...and for kicks I just tried this on W7 under Cygwin 3.0.7.  The output
> > is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html
> > 
> > No 'l' mode flag, no 6th column in the mode output:
> > 
> > Mode                LastWriteTime     Length Name
> > ----                -------------     ------ ----
> > -a---        03.03.2020     16:47          0 bar
> > 
> > 
> For me it's different. That's realy strange.
> 
> Ok, so I can't rely on powershell here. Is there a recommended procedure
> for what I try in a script?
> 
> Check if the current cygwin environment is able to create native symlinks.

Unless I'm missing some new and shiny Windows onboard tool, that's
surprisingly tricky without creating your own executable checking just
that.  Off the top of my head I don't see any other way than calling cmd
/c dir and some awk or sed hacking.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 1754 bytes --]

Am 03.03.2020 um 17:41 schrieb Corinna Vinschen:
> On Mar  3 17:05, Rainer Emrich wrote:
>> Am 03.03.2020 um 16:49 schrieb Corinna Vinschen:
>>> On Mar  3 15:31, Corinna Vinschen wrote:
>>>> On Mar  3 15:19, Rainer Emrich wrote:
>>>>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
>>>>>> Aha!  So powershell does not show the 'l'.
>>>>> The most important thing is the difference between cygwin 3.0.7 and
>>>>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
>>>>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
>>>>> only difference is the cygwin version.
>>>>
>>>> I may believe you, but believe me that Cygwin has no influence on
>>>> what powershell shows.  See the output of cmd /c dir /a.  The file
>>>> is a native symlink.
>>>
>>> ...and for kicks I just tried this on W7 under Cygwin 3.0.7.  The output
>>> is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html
>>>
>>> No 'l' mode flag, no 6th column in the mode output:
>>>
>>> Mode                LastWriteTime     Length Name
>>> ----                -------------     ------ ----
>>> -a---        03.03.2020     16:47          0 bar
>>>
>>>
>> For me it's different. That's realy strange.
>>
>> Ok, so I can't rely on powershell here. Is there a recommended procedure
>> for what I try in a script?
>>
>> Check if the current cygwin environment is able to create native symlinks.
> 
> Unless I'm missing some new and shiny Windows onboard tool, that's
> surprisingly tricky without creating your own executable checking just
> that.  Off the top of my head I don't see any other way than calling cmd
> /c dir and some awk or sed hacking.
Thank you, that's what I thought.

Rainer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Change in logical link behaviour

[Andrey Repin]

Greetings, Rainer Emrich!

> Ok, so I can't rely on powershell here. Is there a recommended procedure
> for what I try in a script?

> Check if the current cygwin environment is able to create native symlinks.

There's more than just Cygwin involved.

1. Target FS may not support symlinks.
2. User may not have necessary permission.

If, for some reason, you DO actually required to create symlinks, go with
winsymlinks:native, they are safer for use and relatively well supported in
other tools.


-- 
With best regards,
Andrey Repin
Wednesday, March 4, 2020 21:50:02

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple