This is the mail archive of the cygwin-developers 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: native symlink support should fallback to default format if target missing


On May 14 11:54, Jeffrey Altman wrote:
> On 5/14/2013 11:04 AM, Corinna Vinschen wrote:
> > But here's the deal:
> > 
> > If the user *deliberately* added CYGWIN=winsymlinks:native to the
> > call, then the user *deliberately* wants to generate native symlinks.
> > The *only* good reason to do that is to support the usage of the
> > symlinks from native (==non-Cygwin) tools.
> > 
> > Now consider:  If you silently create cygwin symlinks, the symlink
> > will be unusable for native tools and your use case will be broken.
> > 
> > OTOH, if it doesn't matter if native tools work with that symlink, then
> > why did you set CYGWIN=winsymlinks:native at all?
> > 
> > So, cgf has a good point here, IMHO.  Either you don't care for
> > interoperability of the symlink, then don't set
> > CYGWIN=winsymlinks:native.  Or, if interoperability is important, set
> > CYGWIN=winsymlinks:native, but then creating a non-native symlink
> > doesn't make sense.
> > 
> > This is a valid argument which has to be seriously considered.
> > 
> > 
> > Corinna
> 
> I definitely see Christopher's point and I am very sympathetic to it as
> someone that has to support a large anonymous user community.  Provide
> rope but not enough to permit the user to hang themselves from the
> perspective of losing data through a lack of understanding of a how a
> feature works.
> 
> I suspect the behavior that James really wants is the following:
> 
>  1. if the target of a symlink exists and the underlying file system
>     supports symlink reparse points, create a symlink reparse point.
> 
>  2. if underlying file system doesn't support symlink reparse points,
>     generate an error.

We're falling back to Cygwin symlinks here.  The check for the FS
capabilities is always done since, for instance, MVFS doesn't support
the SYSTEM bit so only .lnk files work as symlinks, and NFS supports
real symlinks so it gets real symlinks.

>  3. if the target of a symlink doesn't exist, create a cygwin
>     symlink as a place holder.
> 
>  4. if a cygwin symlink is accessed and the target exists and the
>     file system supports symlink reparse points, replace the cygwin
>     symlink with the symlink reparse point.

No, that won't happen.  When reading a symlink it will be used, not
overwritten with another one under some weird circumstances.
Consider:

  $ export CYGWIN=winsymlinks:native
  $ ln -s foo bar
  $ [... doing some other unrelated stuff, forgetting to unset CYGWIN...]
  $ find . -name baz

This will accidentally read all symlinks under CWD and convert them to
native symlinks.  Nope, not good.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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