X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=FQ
	F09vUCful+JwFgH1MOrGMwV3aAY70p8lLhqz207XwdBHuG/chaVtlFJJlRwr7qOB
	qzuulMbE+BqMGTO63QWgz9t7kBUI9I5f4NyFpuvIqWX7ifWnSXU2URdOw5c2HmFL
	nAqqYN8R/UI5UUgtSn+tBgrgiDMA40KKX87AMShx8=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=nC/VjAON
	YEemxOJnT0dyFJw5IWI=; b=wUQ048QWJNcGV1O1F/D4rGkh748k7FwYhpte6CX2
	uRUS4OjidjPFgeHgyHpD+QeEwudmqNLAj9wYg3nVvlRYhmdpc0KxaeojQTaV9Tpw
	2hk+ki9H7WPzK9qR1/ItwZclhB+geLV5DrJZByzlDQIHJFFX3o6m2SzDVSfItr3S
	FEE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.6 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Rosin, rosin, contrast, altogether
X-HELO:	mail-ig0-f180.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=hDg2Be97u6haYqwvROEeT9UND/u1sW1XTTjNveJqdKY=; b=ciHmmZg/cdWcS5RKtUuGQ86m37EgKqg68D6qO8gfFnGH4IKYkM9pEbaWkgFOh9lTX6 nYR4O+/drfeE3/MVqeJMFe2iQ9/hcLYUl3NSqhNPCA+cUxCmFvaPh1rg/Xatwlk83oMC 8vvF86tY/cu610nNg+is61tMajdXfa5l7QftCocoYlhKcAAq31MLOHQFHfAKS9daaQXh BLbUSkPzO7B/w0ugjpkLjeCktB8DF01gcCdEEg/fwLT7i8gl3ilCFTabVq9KVngOqkiD vV9CMc8BJHnt413FlJtc//xi2hBAPK8KKjQY+kGmmsikkZBu52oO/1S01EsFgo/pplz2 SXGA==
X-Gm-Message-State:	AOPr4FXA558zqBZ+g/tHDnmEgvKn2jw6/6BxENOsDSxuvgyRpWkizPctaUZNLzMCSaBgMt3b/8+/3HqYMi8m2g==
MIME-Version:	1.0
X-Received:	by 10.50.183.132 with SMTP id em4mr7605522igc.50.1461975266772; Fri, 29 Apr 2016 17:14:26 -0700 (PDT)
In-Reply-To:	<5580e7fc-e227-d9d8-a186-b58c8b17cfa3@lysator.liu.se>
References:	<CAPTiy3NUXprQL6V0+Njc2L7XfhpqtC7oWFwNMhOEFZ2OZmddoQ AT mail DOT gmail DOT com> <1606116423 DOT 20160429020650 AT yandex DOT ru> <CAPTiy3OhkvWhGKCisnoLBFZqTL1_Rcq4-vdn0U8Qfnxk+WsX-A AT mail DOT gmail DOT com> <5580e7fc-e227-d9d8-a186-b58c8b17cfa3 AT lysator DOT liu DOT se>
Date:	Sat, 30 Apr 2016 03:14:26 +0300
Message-ID:	<CAPTiy3MvtHccWMTcsd3hrgPr3zGDgedZWrcOHpu-Gj+jyaZ8wg@mail.gmail.com>
Subject:	Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist
From:	Gene Pavlovsky <gene DOT pavlovsky AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

I can confirm this behavior. Basically, mklink requires to choose file
(default) or directory (/D) link. It is true whether or not the target
exists (e.g. if your target is a directory,
/D is not implied automatically, you have to specify it). By contrast,
POSIX symlink doesn't distinguish file or directory symlinks.
So, what does it have to do with the topic exactly? According to your
logic, this is alos not good enough:

c:\>mkdir tmp

c:\>cd tmp

c:\tmp>mkdir target

c:\tmp>mklink /d link target
symbolic link created for link <<===>> target

c:\tmp>cd link

c:\tmp\link>cd ..

c:\tmp>rmdir target

c:\tmp>echo file >target

c:\tmp>cd link
The directory name is invalid.

c:\tmp>cat link
file

But it doesn't mean Cygwin should stop offering to use native symlinks
altogether, does it? What I mean is, POSIX symlinks are universal, and
NTFS symlinks are of two kinds. Using native symlinks, therefore, can
create potential problems, regardless of native or nativestrict mode.

I can see allowing dangling native symlinks can be a problem if
there's some script that creates some (dangling) symlinks, and then
later create some directories, to which the links are supposed to
point to, but since they didn't exist at link creation time, the links
are wrongfully of the file kind, and are not gonna work. I guess a
script like this can theoretically exist, even though it sounds quite
purposeless. Is this your concern? Then again, even crazier script can
exist, which creates a symlink pointing somewhere once, and then later
that somewhere can be removed and replaced with either a file or a
directory (sounds crazy and useless, but who knows? it's possible).
This script naturally will be broken whenever using native symlinks at
all.

I think some choice should be made here:
a) Allow creationg of dangling native symlinks (file by default).
b) Add a third native mode which is less strict than `nativestrict`,
but more strict than `native` - I'd like to use `nativestrict` on my
system, but due to this issue I have to use `native`.
c) Explicitly mention this behavior in Cygwin User Guide, so people
know that using `nativestrict` can break some scripts that rely on
creation of dangling symlinks. Currently the wording in CUG sounds
like it might fail because the filesystem doesn't support symlinks or
something.

Thanks.
--Gene


On 29 April 2016 at 15:02, Peter Rosin <peda AT lysator DOT liu DOT se> wrote:
> On 2016-04-29 13:34, Gene Pavlovsky wrote:
>>>> POSIX says a symlink to a missing target is perfectly well-defined (you
>>>> can't stat() through it, but you can readlink() it). But Windows native
>>>> symlinks can't do that.  So the problems you are encountering all stem
>>>> from the fact that you are trying to make Windows do something it can't.
>>>
>>> My initial reaction was that, too, but I tried mklink (CMD internal command)
>>>
>>>> mklink x y
>>>
>>> and it created the symlink in the empty directory just fine.
>>
>> This is my point exactly. Windows dangling symlinks can be created as
>> easily as in UNIX.
>> At least this is the case on my Win7 x64.
>
> No, it can't.
>
> c:\>mklink a b
> c:\>mkdir b
> c:\>cd b
> c:\b>cd ..
> c:\>cd a
> The directory name is invalid
> c:\>rmdir b
> c:\>echo hello > b
> c:\>type a
> hello
>
> It only works for dangling links to files. Not good enough.
>
> Cheers,
> Peter

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

- Raw text -