public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: David Macek <david.macek.0@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Symlink targets dereferenced when winsymlinks:native
Date: Thu, 19 Nov 2015 18:53:00 -0000	[thread overview]
Message-ID: <564E1AA0.6070001@gmail.com> (raw)
In-Reply-To: <20151118194819.GV6402@calimero.vinschen.de>

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

  parent reply	other threads:[~2015-11-19 18:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17 22:28 David Macek
2015-11-18 17:55 ` Corinna Vinschen
2015-11-18 18:13   ` David Macek
2015-11-18 19:48     ` Corinna Vinschen
2015-11-18 20:01       ` Warren Young
2015-11-18 20:07         ` Corinna Vinschen
2015-11-19 18:53       ` David Macek [this message]
2015-11-19 19:36         ` Nellis, Kenneth
2015-11-19 21:17           ` David Macek
2015-11-20  9:26             ` Corinna Vinschen
2015-11-24 21:48               ` David Macek
2015-11-26 12:02                 ` Corinna Vinschen
2015-11-29 14:10                   ` David Macek
2015-11-29 17:10                     ` Corinna Vinschen
2015-11-20  9:29         ` Corinna Vinschen
2015-11-24 19:51           ` David Macek
2015-11-25  3:20   ` Linda Walsh
2015-11-25 14:59     ` David Macek
2015-11-26 11:53       ` Another reason to not corrupt winnative symlinks: :currenly, they are linux-CIFS compat. Cygwin's are not Linda Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564E1AA0.6070001@gmail.com \
    --to=david.macek.0@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).