Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Nov 24 20:51, David Macek wrote:
> On 20. 11. 2015 10:26, Corinna Vinschen wrote:
> > On Nov 19 22:17, David Macek wrote:
> >> On 19. 11. 2015 20:36, Nellis, Kenneth wrote:
> >>> 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
> >>> $
> >>
> >> Weird. I also tried in the virtual root directory, in case cygdrive affects it, but no luck, still absolute paths.
> >>
> >> I'm on Windows 10, if it makes any difference.
> > 
> > No, I'm on W10 either and it works for me as for Kenneth.  The path
> > evaluation in the function creating native symlinks tries to create
> > relative Windows paths if the incoming target path is relative, too.
> > Basically it compares the path prefixes, eliminates as much of
> > the path as possible and prepends "..\\" as required.
> > 
> > I don't see a reason why this shouldn't work for you, unless the
> > shell mangles the paths before passing them to the ln command (yes,
> > this really may happen with some shells depending on settings)
> 
> It seems it's dependent on the directory after all. The shell doesn't seem to affect it, at least not in my tests.
> 
> My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. Now the results:
> 
> in /bin/: relative
> in /: absolute
> in ~/ (/cygdrive/c/Users/username/): relative
> in /cygdrive/w/: absolute
> 
> Note that W: is a permasubst (created using `DOSDevices` in registry), which would explain the different behaviour (but not excuse it :), but I don't see why / is also special. Even if only one from the link pair (target or source) is in a relative-symlink-unsupporting path, I get an absolute path.
> 
> Can you confirm?

Yes, thanks for this part of the analysis.  There was a typo in the
code checking the relative paths.  The check for a drive colon in the
pathname used a wrong offset into the path string, which ultimately
always created an absolut path to the target if the path of the
target was in a drive's root dir or one level below that.

I fixed that in the repo and created a new developer snapshot for
testing: https://cygwin.com/snapshots/  Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpsF8Pt0P69k.pgp
Description: PGP signature