Symlink targets dereferenced when winsymlinks:native

Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Warren Young]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

RE: 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

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Re: Symlink targets dereferenced when winsymlinks:native

[Linda Walsh]

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    <DIR>          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

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4254 bytes --]

Another reason to not corrupt winnative symlinks: :currenly, they are linux-CIFS compat. Cygwin's are not.

[Linda Walsh]

David Macek wrote:
> 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.
> 
---
Notice the date on it... I created it 2-3 years ago...
but it was likely to get some behavior to work the same
with windows utils and linux utils.  I have my cygroot
set to '/' (sorta)...and paths on my linux box and windows 
box often resolve to the same file.  Since the underlying 
NT OS is slash impartial, many pathnames will work w/o conversion.

That's why I tried to get Corrina to support the MS-View of 
MS-junctions being the MS-equiv of linux Mount-points --
She's wiping out linux compatibility by turning them into
the same as 'symlinkd' entries.

I also had both cygwin32 and cygwin64 working on my system
at the same time, with win-applications invoking the 'correct
bit-wise versions and libs by using Ms's 32/64-bit 'system32'
redirect, but having things like tar and rsync ovewrite your
mountpoints on every install and update made it a high maintenance
task.

Basically my login to both machines looks very similar -- same
bash setup.

What was really 'cool' is mounting my win-fs near the root
and having the Windows symlinks ... this is another good reason
not to screw w/things... it will break linux compatibility
even more...   The symlinks on Windows work as unix symlinks
when the share is mounted on a unix dir.  So on linux, I see:
l--------- 1            0 Jul 16  2013 D -> /??/UNC/Ishtar/Documents/
l--------- 1            0 Feb 28  2015 M -> /??/UNC/Bliss/Music/
l--------- 1            0 Feb 28  2015 P -> /??/UNC/Bliss/Pictures/
l--------- 1            0 Mar 28  2013 Share -> /??/UNC/Bliss/Share/
l--------- 1            0 Apr 21  2013 prog64 -> Program Files/
===(among others)...
But those links resolve on linux - I just
created a dir in root named '??'.. etc. and filled
out the structure... so file access on from my linux
machine can resolve seemlessly.  If corrina changes
to a non-compatible symlink format then they won't resolve
as linux symlinks under linux CIFS.





--
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