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