Symlink targets dereferenced when winsymlinks:native

[Nellis, Kenneth]

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