This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <> 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:
> FAQ:         
> Documentation:
> Unsubscribe info:

Attachment: 0005-native-symlinks-non-exist-target-support.patch
Description: application/itunes-itlp

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]