Re: Symlink targets dereferenced when winsymlinks:native
On Nov 29 15:00, David Macek wrote: > On 26. 11. 2015 12:53, Corinna Vinschen wrote: > > On Nov 24 20:51, David Macek wrote: > >> 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. > > I get relative symlinks in all of my test cases now. Thanks. Cool, thanks for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpc8DOv0sNpl.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
On 26. 11. 2015 12:53, Corinna Vinschen wrote: > On Nov 24 20:51, David Macek wrote: >> 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. I get relative symlinks in all of my test cases now. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
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 pgp0hbWnEf3xu.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
Can you describe what purpose does your C:\proc serve? I'm not currently arguing for or against Corinna's proposal, I'm just curious. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
Corinna Vinschen wrote: If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. It matters. This is a bug in Cygwin, a missing test in fact. It should never allow to create native symlinks to targets which only exist inside of Cygwin. Please don't. Why? It would be a built-in behavior difference between unix/linux symlinks and cygwin. symlink create on unix/linux doesn't look at the 'source' and create different types of links or different behaviors based on some ill-considered 'pathname filtering'. Consider that /proc/self/fd has no meaning to non-Cygwin processes at all. --- Unless you have a file-system driver, or a ".desktop.ini" in a windows created 'C:\Proc\.desktop.ini that redirects handlers for \proc to something similar. On my system, when I look at /proc/self/fd in cygwin+windows: cyg: /> ll /proc/self/fd total 0 lrwxrwxrwx 1 0 Nov 24 17:58 0 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 1 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 2 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 3 -> /proc/21920/fd/ win: /> cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\>dir \proc\self\fd /w dir \proc\self\fd /w Volume in drive C is System Disk Volume Serial Number is E889-68E4 Directory of C:\proc\self\fd [.] [..] 0 File(s) 0 bytes 2 Dir(s) 401,855,094,784 bytes free i.e. it shows a directory that is empty, and according to windows, was created over a year ago: C:\>dir |grep -i proc dir |grep -i proc 01/23/2014 05:13 PM proc As soon as you start prohibiting normal 'native' link creation based on some assumption about "who owns the path", I can't see how that won't end up biting you later. -- 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: Symlink targets dereferenced when winsymlinks:native
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? Output of `mount`: D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) D:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,posix=0,user,noumount,auto) -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 20. 11. 2015 10:29, Corinna Vinschen wrote: > On Nov 19 19:53, David Macek wrote: >> 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. > > Symlinks within the path, e.g : /home/foo/symlink/bar/baz > > If the above symlink is not a native symlink, the above path > converted to Windows notation > > C:\cygwin64\home\foo\symlink\bar\baz > > is invalid. Ah. Now I understand. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On Nov 19 19:53, David Macek wrote: > 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. Symlinks within the path, e.g : /home/foo/symlink/bar/baz If the above symlink is not a native symlink, the above path converted to Windows notation C:\cygwin64\home\foo\symlink\bar\baz is invalid. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXN8zqQEmMY.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
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) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBaL9ZyBagq.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
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. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
RE: Symlink targets dereferenced when winsymlinks:native
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
Re: Symlink targets dereferenced when winsymlinks:native
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. >> Should that behaviour stay? > > Yes. Consider that neither Cygwin or Interix symlinks with SYSTEM bit > set, nor symlinks using WIndows shortcuts make any sense as part of a > native symlink. As a result, Cygwin does a full path conversion from > POSIX to symlink-less Windows path to crate native symlinks. I'm sorry, but I'm not sure I understand. What does "to be as part of a symlink" mean in this context and how did non-NTFS symlinks get into the discussion? *** After thinking about this for some time, I began to assume that "part of a symlink" was meant as "a symlink target". In that case, it seems that Cygwin is pretty intelligent about this, as the dereferencing only happens when targetting a non-NTFS symlink, at least in trivial cases. If that's the case, then I'm okay with that (and I'll try to document it), and the only question that remains is the one about relative paths (see above). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On Nov 18 13:01, Warren Young wrote: > On Nov 18, 2015, at 12:48 PM, Corinna Vinschen wrote: > > > >> If not, I can send a patch for the UG. > > > > UG? > > User guide. Ouch, right, thanks :) Patches to the documentation are *always* welcome. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5mqVIHcJuy.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
On Nov 18, 2015, at 12:48 PM, Corinna Vinschen wrote: > >> If not, I can send a patch for the UG. > > UG? User guide. -- 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: Symlink targets dereferenced when winsymlinks:native
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: > >> Hi. > >> > >> 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. > > Should that behaviour stay? Yes. Consider that neither Cygwin or Interix symlinks with SYSTEM bit set, nor symlinks using WIndows shortcuts make any sense as part of a native symlink. As a result, Cygwin does a full path conversion from POSIX to symlink-less Windows path to crate native symlinks. > If not, I can send a patch for the UG. UG? > > Thanks for the report, I'll apply a matching patch. > > Cool. https://sourceware.org/git/?p=newlib-cygwin.git;h=8cdd7bad219ba2657e381bd0d716594c50a6ef62 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvwz2U4wL5Y.pgp Description: PGP signature
Re: Symlink targets dereferenced when winsymlinks:native
On 18. 11. 2015 18:55, Corinna Vinschen wrote: > On Nov 17 23:28, David Macek wrote: >> Hi. >> >> 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. Should that behaviour stay? If not, I can send a patch for the UG. >> That doesn't happed when >> using regular symlink files. Is this behaviour intentional / known? >> >> If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. > > It matters. This is a bug in Cygwin, a missing test in fact. It should > never allow to create native symlinks to targets which only exist inside > of Cygwin. Consider that /proc/self/fd has no meaning to non-Cygwin > processes at all. Creating this symlink as native symlink doesn't make > any sense, they should always be generated as Cygwin-only symlinks. > > Thanks for the report, I'll apply a matching patch. Cool. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On Nov 17 23:28, David Macek wrote: > Hi. > > 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. > That doesn't happed when > using regular symlink files. Is this behaviour intentional / known? > > If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. It matters. This is a bug in Cygwin, a missing test in fact. It should never allow to create native symlinks to targets which only exist inside of Cygwin. Consider that /proc/self/fd has no meaning to non-Cygwin processes at all. Creating this symlink as native symlink doesn't make any sense, they should always be generated as Cygwin-only symlinks. Thanks for the report, I'll apply a matching patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1k3vzaiPCx.pgp Description: PGP signature
Symlink targets dereferenced when winsymlinks:native
Hi. 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. That doesn't happed when using regular symlink files. Is this behaviour intentional / known? If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
