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

[Rinrin <rinrin@imbrian.org>]

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

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
> 


[-- Attachment #2: 0005-native-symlinks-non-exist-target-support.patch --]
[-- Type: application/x-itunes-itlp, Size: 4103 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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