From: David Macek > On 18. 11. 2015 20:48, Corinna Vinschen wrote: > > On Nov 18 19:13, David Macek wrote: > >> On 18. 11. 2015 18:55, Corinna Vinschen wrote: > >>> On Nov 17 23:28, David Macek wrote: > >>>> I went through the UG looking for differences between regular Cygwin > >>>> symlinks and NTFS symlinks, but couldn't find this documented. It > >>>> seems that when using winsymlinks:native, the target path is first > >>>> dereferenced before storing it in the link. > >>> > >>> It's a result of the native symlink being a Windows path. The > >>> ultimate conversion from POSIX to Windows path dereferences all > >>> symlinks. > > Hmm. I just performed a test on my Cygwin installation and it doesn't seem > to match the described behavior. > > /cygdrive/w/temp $ export CYGWIN=winsymlinks:nativestrict > /cygdrive/w/temp $ touch XXX > /cygdrive/w/temp $ ln -s XXX YYY > /cygdrive/w/temp $ ln -s YYY ZZZ > /cygdrive/w/temp $ ls -l > ... > -rwxrwxr--+ ... XXX > lrwxrwxrwx ... YYY -> /cygdrive/w/temp/XXX > lrwxrwxrwx ... ZZZ -> /cygdrive/w/temp/YYY > > What's interesting though, is that the paths are converted to absolute > ones. This again only happens for winsymlinks:native, but NTFS symlinks > have no such restriction and `mklink` happily creates relative links.
FWIW, my results are different: $ printenv CYGWIN winsymlinks:nativestrict $ touch XXX $ ln -s XXX YYY $ ln -s YYY ZZZ $ ls -l total 0 -rw-r----- 1 knellis Domain Users 0 Nov 19 14:28 XXX lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY $ uname -svr CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 $ --Ken Nellis
