This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]