`CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist
Rinrin
rinrin@imbrian.org
Wed Oct 5 03:56:00 GMT 2016
Hi Gene:
I made a patch for my private use.
First of all, you should setup `nativenocheck` in CYGWIN environment
variable to enable this feature.
If the target does not exist, it will check the last digit of target
path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>
å¨ 2016/4/30 8:14, Gene Pavlovsky åé:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-native-symlinks-non-exist-target-support.patch
Type: application/x-itunes-itlp
Size: 4103 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20161005/7edc13b7/attachment.bin>
-------------- next part --------------
--
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
More information about the Cygwin
mailing list