native symlink support should fallback to default format if target missing

[Corinna Vinschen]

On May 14 08:52, James Gregurich wrote:
> 
> >> 
> > 
> > I agree with Chris on this.  Instead of a fallback behavior it should
> > be an EACCES, EINVAL or EXDEV error.
> > 
> > -- 
> > Earnie
> > -- https://sites.google.com/site/earnieboyd
> 
> This may sound rational from a theoretical perspective, but for
> practical use of the system, it is not good. Consider the case when
> one clones  a git repository. The link will often be created before
> the target file exists. If the system fails with an error, then you
> won't be able to use your git working tree as the checkout won't be
> successful.

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

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