Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky <gene.pavlovsky@gmail.com>]

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@lysator.liu.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