From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84029 invoked by alias); 5 Oct 2016 03:03:28 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 83871 invoked by uid 89); 5 Oct 2016 03:03:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=D*se, welldefined, well-defined, H*i:sk:CAPTiy3 X-HELO: mail.imbrian.org Received: from li1009-235.members.linode.com (HELO mail.imbrian.org) (45.33.59.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Oct 2016 03:03:04 +0000 Subject: Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist To: cygwin@cygwin.com References: <1606116423.20160429020650@yandex.ru> <5580e7fc-e227-d9d8-a186-b58c8b17cfa3@lysator.liu.se> From: Rinrin Message-ID: <206e8a55-a830-fb27-76e1-dfe4c47ac51f@imbrian.org> Date: Wed, 05 Oct 2016 03:56:00 -0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------CF3622E5244F1E1A5AA25D28" X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00057.txt.bz2 --------------CF3622E5244F1E1A5AA25D28 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-length: 4070 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 > --------------CF3622E5244F1E1A5AA25D28 Content-Type: application/x-itunes-itlp; name="0005-native-symlinks-non-exist-target-support.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0005-native-symlinks-non-exist-target-support.patch" Content-length: 5564 ZGlmZiAtQnVyTiBuZXdsaWItY3lnd2luL3dpbnN1cC9jeWd3aW4vZW52aXJv bi5jYyBuZXdsaWItY3lnd2luLm5ldy93aW5zdXAvY3lnd2luL2Vudmlyb24u Y2MKLS0tIG5ld2xpYi1jeWd3aW4vd2luc3VwL2N5Z3dpbi9lbnZpcm9uLmNj CTIwMTYtMTAtMDUgMTA6NTI6NDEuMjE5MzY0MjAwICswODAwCisrKyBuZXds aWItY3lnd2luLm5ldy93aW5zdXAvY3lnd2luL2Vudmlyb24uY2MJMjAxNi0x MC0wNSAxMDo0NTozNi41MTU2MTc3MDAgKzA4MDAKQEAgLTgzLDggKzgzLDE0 IEBACiAgICAgYWxsb3dfd2luc3ltbGlua3MgPSBXU1lNX2xuazsKICAgLyog TWFrZSBzdXJlIHRvIHRyeSBuYXRpdmUgc3ltbGlua3Mgb25seSBvbiBzeXN0 ZW1zIHN1cHBvcnRpbmcgdGhlbS4gKi8KICAgZWxzZSBpZiAoYXNjaWlfc3Ry bmNhc2VtYXRjaCAoYnVmLCAibmF0aXZlIiwgNikpCi0gICAgYWxsb3dfd2lu c3ltbGlua3MgPSBhc2NpaV9zdHJjYXNlbWF0Y2ggKGJ1ZiArIDYsICJzdHJp Y3QiKQotCQkJPyBXU1lNX25hdGl2ZXN0cmljdCA6IFdTWU1fbmF0aXZlOwor ICB7CisgICAgaWYgKGFzY2lpX3N0cmNhc2VtYXRjaCAoYnVmICsgNiwgInN0 cmljdCIpKQorICAgICAgYWxsb3dfd2luc3ltbGlua3MgPSBXU1lNX25hdGl2 ZXN0cmljdDsKKyAgICBlbHNlIGlmIChhc2NpaV9zdHJjYXNlbWF0Y2ggKGJ1 ZiArIDYsICJub2NoZWNrIikpCisgICAgICBhbGxvd193aW5zeW1saW5rcyA9 IFdTWU1fbmF0aXZlbm9jaGVjazsKKyAgICBlbHNlCisgICAgICBhbGxvd193 aW5zeW1saW5rcyA9IFdTWU1fbmF0aXZlOworICB9CiB9CiAKIC8qIFRoZSBz dHJ1Y3R1cmUgYmVsb3cgaXMgdXNlZCB0byBzZXQgdXAgYW4gYXJyYXkgd2hp Y2ggaXMgdXNlZCB0bwpkaWZmIC1CdXJOIG5ld2xpYi1jeWd3aW4vd2luc3Vw L2N5Z3dpbi9nbG9iYWxzLmNjIG5ld2xpYi1jeWd3aW4ubmV3L3dpbnN1cC9j eWd3aW4vZ2xvYmFscy5jYwotLS0gbmV3bGliLWN5Z3dpbi93aW5zdXAvY3ln d2luL2dsb2JhbHMuY2MJMjAxNi0wOC0zMSAyMDoyNjoxMi4wMDAwMDAwMDAg KzA4MDAKKysrIG5ld2xpYi1jeWd3aW4ubmV3L3dpbnN1cC9jeWd3aW4vZ2xv YmFscy5jYwkyMDE2LTEwLTA1IDEwOjQ1OjM2LjA5MjA2NDAwMCArMDgwMApA QCAtNTUsNiArNTUsNyBAQAogICBXU1lNX2xuaywKICAgV1NZTV9uYXRpdmUs CiAgIFdTWU1fbmF0aXZlc3RyaWN0LAorICBXU1lNX25hdGl2ZW5vY2hlY2ss CiAgIFdTWU1fbmZzCiB9OwogCmRpZmYgLUJ1ck4gbmV3bGliLWN5Z3dpbi93 aW5zdXAvY3lnd2luL3BhdGguY2MgbmV3bGliLWN5Z3dpbi5uZXcvd2luc3Vw L2N5Z3dpbi9wYXRoLmNjCi0tLSBuZXdsaWItY3lnd2luL3dpbnN1cC9jeWd3 aW4vcGF0aC5jYwkyMDE2LTEwLTA1IDEwOjUyOjQ3LjMyMTIwOTAwMCArMDgw MAorKysgbmV3bGliLWN5Z3dpbi5uZXcvd2luc3VwL2N5Z3dpbi9wYXRoLmNj CTIwMTYtMTAtMDUgMTA6NDU6MzYuMTgxMTMzNTAwICswODAwCkBAIC0xNjQ5 LDcgKzE2NDksNyBAQAogfQogCiBzdGF0aWMgaW50Ci1zeW1saW5rX25hdGl2 ZSAoY29uc3QgY2hhciAqb2xkcGF0aCwgcGF0aF9jb252ICZ3aW4zMl9uZXdw YXRoKQorc3ltbGlua19uYXRpdmUgKGNvbnN0IGNoYXIgKm9sZHBhdGgsIHBh dGhfY29udiAmd2luMzJfbmV3cGF0aCwgaW50IGNoZWNrZmxhZykKIHsKICAg dG1wX3BhdGhidWYgdHA7CiAgIHBhdGhfY29udiB3aW4zMl9vbGRwYXRoOwpA QCAtMTcxOSw3ICsxNzE5LDcgQEAKICAgICAgT3RoZXJ3aXNlIHRoZSBkaXJl Y3RvcnkgZmxhZyBpbiB0aGUgc3ltbGluayBpcyBwb3RlbnRpYWxseSB3cm9u ZwogICAgICB3aGVuIHRoZSB0YXJnZXQgY29tZXMgaW50byBleGlzdGVuY2Us IGFuZCBuYXRpdmUgdG9vbHMgd2lsbCBmYWlsLgogICAgICBUaGlzIGlzIHNv IHNjcmV3YmFsbC4gVGhpcyBpcyBubyBwcm9ibGVtIG9uIEFGUywgZm9ydHVu YXRlbHkuICovCi0gIGlmICghd2luMzJfb2xkcGF0aC5leGlzdHMgKCkgJiYg IXdpbjMyX29sZHBhdGguZnNfaXNfYWZzICgpKQorICBpZiAoIXdpbjMyX29s ZHBhdGguZXhpc3RzICgpICYmICF3aW4zMl9vbGRwYXRoLmZzX2lzX2FmcyAo KSAmJiBjaGVja2ZsYWcgPT0gMSkKICAgICB7CiAgICAgICBTZXRMYXN0RXJy b3IgKEVSUk9SX0ZJTEVfTk9UX0ZPVU5EKTsKICAgICAgIHJldHVybiAtMTsK QEAgLTE3NTIsOSArMTc1MiwxNyBAQAogCWZpbmFsX29sZHBhdGgtPkJ1ZmZl clsxXSA9IEwnXFwnOwogICAgIH0KICAgLyogVHJ5IHRvIGNyZWF0ZSBuYXRp dmUgc3ltbGluay4gKi8KLSAgaWYgKCFDcmVhdGVTeW1ib2xpY0xpbmtXIChm aW5hbF9uZXdwYXRoLT5CdWZmZXIsIGZpbmFsX29sZHBhdGgtPkJ1ZmZlciwK LQkJCSAgICB3aW4zMl9vbGRwYXRoLmlzZGlyICgpCi0JCQkgICAgPyBTWU1C T0xJQ19MSU5LX0ZMQUdfRElSRUNUT1JZIDogMCkpCisgIC8qIEZvciBub24t ZXhpc3QgdGFyZ2V0LCB0cmVhdCBwYXRoIHdpdGggc2xhc2ggaW4gdGhlIGVu ZCBhcyBkaXJlY3RvcnkgKi8KKyAgaW50IGlzZGlyZmxhZyA9MDsKKyAgaWYg KHdpbjMyX29sZHBhdGguaXNkaXIgKCkpCisgICAgaXNkaXJmbGFnPVNZTUJP TElDX0xJTktfRkxBR19ESVJFQ1RPUlk7CisgIGVsc2UgaWYgKCF3aW4zMl9v bGRwYXRoLmV4aXN0cyAoKSAmJiBjaGVja2ZsYWcgPT0gMCkKKyAgeworICAg IGNoYXIgKmxhc3RzbGFzaD1zdHJyY2hyKG9sZHBhdGgsJy8nKTsKKyAgICBp ZihsYXN0c2xhc2ggJiYgc3RybGVuKG9sZHBhdGgpIC0gKGxhc3RzbGFzaC1v bGRwYXRoKSA9PSAxKQorICAgICAgaXNkaXJmbGFnPVNZTUJPTElDX0xJTktf RkxBR19ESVJFQ1RPUlk7CisgIH0KKyAgaWYgKCFDcmVhdGVTeW1ib2xpY0xp bmtXIChmaW5hbF9uZXdwYXRoLT5CdWZmZXIsIGZpbmFsX29sZHBhdGgtPkJ1 ZmZlcixpc2RpcmZsYWcpKQogICAgIHsKICAgICAgIC8qIFJlcGFpciBuYXRp dmUgbmV3cGF0aCwgd2Ugc3RpbGwgbmVlZCBpdC4gKi8KICAgICAgIGZpbmFs X25ld3BhdGgtPkJ1ZmZlclsxXSA9IEwnPyc7CkBAIC0xODE5LDcgKzE4Mjcs OCBAQAogICAgICAgZWxzZSBpZiAod2luMzJfbmV3cGF0aC5mc19pc19hZnMg KCkpCiAJd3N5bV90eXBlID0gV1NZTV9uYXRpdmVzdHJpY3Q7CiAgICAgICAv KiBEb24ndCB0cnkgbmF0aXZlIHN5bWxpbmtzIG9uIEZTZXMgbm90IHN1cHBv cnRpbmcgcmVwYXJzZSBwb2ludHMuICovCi0gICAgICBlbHNlIGlmICgod3N5 bV90eXBlID09IFdTWU1fbmF0aXZlIHx8IHdzeW1fdHlwZSA9PSBXU1lNX25h dGl2ZXN0cmljdCkKKyAgICAgIGVsc2UgaWYgKCh3c3ltX3R5cGUgPT0gV1NZ TV9uYXRpdmUgfHwgd3N5bV90eXBlID09IFdTWU1fbmF0aXZlc3RyaWN0Cisg ICAgICAgICAgIHx8IHdzeW1fdHlwZSA9PSBXU1lNX25hdGl2ZW5vY2hlY2sp CiAJICAgICAgICYmICEod2luMzJfbmV3cGF0aC5mc19mbGFncyAoKSAmIEZJ TEVfU1VQUE9SVFNfUkVQQVJTRV9QT0lOVFMpKQogCXdzeW1fdHlwZSA9IFdT WU1fc3lzZmlsZTsKIApAQCAtMTg2MSw3ICsxODcwLDcgQEAKIAkgIF9fbGVh dmU7CiAJY2FzZSBXU1lNX25hdGl2ZToKIAljYXNlIFdTWU1fbmF0aXZlc3Ry aWN0OgotCSAgcmVzID0gc3ltbGlua19uYXRpdmUgKG9sZHBhdGgsIHdpbjMy X25ld3BhdGgpOworCSAgcmVzID0gc3ltbGlua19uYXRpdmUgKG9sZHBhdGgs IHdpbjMyX25ld3BhdGgsMSk7CiAJICBpZiAoIXJlcykKIAkgICAgX19sZWF2 ZTsKIAkgIC8qIFN0cmljdGx5IG5hdGl2ZT8gIFRvbyBiYWQsIHVubGVzcyB0 aGUgdGFyZ2V0IGlzIGEgQ3lnd2luCkBAIC0xODc0LDYgKzE4ODMsMTYgQEAK IAkgIC8qIE90aGVyd2lzZSwgZmFsbCBiYWNrIHRvIGRlZmF1bHQgc3ltbGlu ayB0eXBlLiAqLwogCSAgd3N5bV90eXBlID0gV1NZTV9zeXNmaWxlOwogCSAg YnJlYWs7CisJY2FzZSBXU1lNX25hdGl2ZW5vY2hlY2s6CisJICByZXMgPSBz eW1saW5rX25hdGl2ZSAob2xkcGF0aCwgd2luMzJfbmV3cGF0aCwwKTsKKwkg IGlmICghcmVzKQorCSAgICBfX2xlYXZlOworCSAgZWxzZSBpZiAocmVzID09 IC0xKQorCSAgICB7CisJICAgICAgX19zZXRlcnJubyAoKTsKKwkgICAgICBf X2xlYXZlOworCSAgICB9CisJICBicmVhazsKIAlkZWZhdWx0OgogCSAgYnJl YWs7CiAJfQo= --------------CF3622E5244F1E1A5AA25D28 Content-Type: text/plain; charset=us-ascii Content-length: 218 -- 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 --------------CF3622E5244F1E1A5AA25D28--