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 instead of 在 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: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >