Re: Change in logical link behaviour
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
Re: Change in logical link behaviour
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: >>> >>> ModeLastWriteTime 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 signature.asc Description: OpenPGP digital signature
Re: Change in logical link behaviour
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: > > > > ModeLastWriteTime 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 signature.asc Description: PGP signature
Re: Change in logical link behaviour
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: > > ModeLastWriteTime 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 signature.asc Description: OpenPGP digital signature
Re: Change in logical link behaviour
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: ModeLastWriteTime Length Name - -- -a---03.03.2020 16:47 0 bar Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Change in logical link behaviour
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 signature.asc Description: PGP signature
Re: Change in logical link behaviour
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
ModeLastWriteTime Length Name
- --
d29.02.2020 13:58asdfgh-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 .
>>> 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
>>>
>> 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
>>
>> ModeLastWriteTime 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
>>
>> ModeLastWriteTime 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 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 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
>
>
> ModeLastWriteTime 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
signature.asc
Description: OpenPGP digital signature
Re: Change in logical link behaviour
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
> >>
> >>
> >> ModeLastWriteTime Length Name
> >> - --
> >> d29.02.2020 13:58asdfgh-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 .
> > 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
> >
> 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
>
> ModeLastWriteTime 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
>
> ModeLastWriteTime 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 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 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
ModeLastWriteTime 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 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
ModeLastWriteTime 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
signature.asc
Description: PGP signature
Re: Change in logical link behaviour
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
>>
>>
>> ModeLastWriteTime Length Name
>> - --
>> dl 29.02.2020 13:58asdfgh-1
>>
>> On cygwin 3.1.4 I get:
>>
>>
>> Directory: D:\cygwin\home\rainer\temp
>>
>>
>> ModeLastWriteTime Length Name
>> - --
>> d29.02.2020 13:58asdfgh-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 .
> 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
>
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
ModeLastWriteTime 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
ModeLastWriteTime 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
signature.asc
Description: OpenPGP digital signature
Re: Change in logical link behaviour
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
>
>
> ModeLastWriteTime Length Name
> - --
> dl 29.02.2020 13:58asdfgh-1
>
> On cygwin 3.1.4 I get:
>
>
> Directory: D:\cygwin\home\rainer\temp
>
>
> ModeLastWriteTime Length Name
> - --
> d29.02.2020 13:58asdfgh-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 .
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
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 .
2020-03-02 17:31 ..
2020-03-02 17:3820 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
signature.asc
Description: PGP signature
Re: Change in logical link behaviour
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
>
>
>> ModeLastWriteTime Length Name
>> - --
>> dl 29.02.2020 13:58asdfgh-1
>
>> On cygwin 3.1.4 I get:
>
>
>> Directory: D:\cygwin\home\rainer\temp
>
>
>> ModeLastWriteTime Length Name
>> - --
>> d29.02.2020 13:58asdfgh-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
signature.asc
Description: OpenPGP digital signature
Re: Change in logical link behaviour
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
> ModeLastWriteTime Length Name
> - --
> dl 29.02.2020 13:58asdfgh-1
> On cygwin 3.1.4 I get:
> Directory: D:\cygwin\home\rainer\temp
> ModeLastWriteTime Length Name
> - --
> d29.02.2020 13:58asdfgh-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
