From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40425 invoked by alias); 30 Apr 2016 00:14:40 -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 40412 invoked by uid 89); 30 Apr 2016 00:14:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Rosin, rosin, contrast, altogether X-HELO: mail-ig0-f180.google.com Received: from mail-ig0-f180.google.com (HELO mail-ig0-f180.google.com) (209.85.213.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 30 Apr 2016 00:14:28 +0000 Received: by mail-ig0-f180.google.com with SMTP id bi2so38181267igb.0 for ; Fri, 29 Apr 2016 17:14:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=hDg2Be97u6haYqwvROEeT9UND/u1sW1XTTjNveJqdKY=; b=ciHmmZg/cdWcS5RKtUuGQ86m37EgKqg68D6qO8gfFnGH4IKYkM9pEbaWkgFOh9lTX6 nYR4O+/drfeE3/MVqeJMFe2iQ9/hcLYUl3NSqhNPCA+cUxCmFvaPh1rg/Xatwlk83oMC 8vvF86tY/cu610nNg+is61tMajdXfa5l7QftCocoYlhKcAAq31MLOHQFHfAKS9daaQXh BLbUSkPzO7B/w0ugjpkLjeCktB8DF01gcCdEEg/fwLT7i8gl3ilCFTabVq9KVngOqkiD vV9CMc8BJHnt413FlJtc//xi2hBAPK8KKjQY+kGmmsikkZBu52oO/1S01EsFgo/pplz2 SXGA== X-Gm-Message-State: AOPr4FXA558zqBZ+g/tHDnmEgvKn2jw6/6BxENOsDSxuvgyRpWkizPctaUZNLzMCSaBgMt3b/8+/3HqYMi8m2g== MIME-Version: 1.0 X-Received: by 10.50.183.132 with SMTP id em4mr7605522igc.50.1461975266772; Fri, 29 Apr 2016 17:14:26 -0700 (PDT) Received: by 10.79.22.134 with HTTP; Fri, 29 Apr 2016 17:14:26 -0700 (PDT) In-Reply-To: <5580e7fc-e227-d9d8-a186-b58c8b17cfa3@lysator.liu.se> References: <1606116423.20160429020650@yandex.ru> <5580e7fc-e227-d9d8-a186-b58c8b17cfa3@lysator.liu.se> Date: Sat, 30 Apr 2016 12:35:00 -0000 Message-ID: Subject: Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist From: Gene Pavlovsky To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00659.txt.bz2 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