native symlink support should fallback to default format if target missing
Mon May 13 19:47:00 GMT 2013
On Mon, May 13, 2013 at 2:59 PM, Christopher Faylor wrote:
> On Mon, May 13, 2013 at 05:40:07PM +0200, Corinna Vinschen wrote:
>>On May 13 11:25, Jeffrey Altman wrote:
>>> On 5/13/2013 11:00 AM, Corinna Vinschen wrote:
>>> > On May 3 14:53, James Gregurich wrote:
>>> >> The guy I have testing the native symlink support in the new cygwin is
>>> >> reporting to me that if the target of the link does not exist, the
>>> >> mechanism is creating a file reparse point. This is not desirable
>>> >> behavior. When the target comes into existence, if it is a folder,
>>> >> then the native symlink is invalid. What the mechanism should do is
>>> >> fall back to the native symlink format if the target doesn't exist.
>>> >> That way, the link is never invalid. Since it is a default format
>>> >> symlink, then my test for the need to replace the link by checking if
>>> >> it is not a reparse point will work. Otherwise, I would have to take
>>> >> into consideration that the reparse point may exist but be invalid.
>>> > Makes sense. I'll fix that shortly.
>>> Don't worry about falling back for AFS. The correct thing will happen
>>> there because AFS does not save the target type information as part of
>>> the backend link information.
>>Thanks for the reminder. I'll keep that in mind for the patch.
> I've had a private discussion with Corinna about this and she asked me
> to make my concerns known.
> It seems to me that if you tell Cygwin to create native windows symlinks
> then, if it is unable to do so, it should not be falling back to using
> its own symlinks. I would think that would be surprising to someone who
> set the CYGWIN environment variable to force that behavior.
> If we fall back then a user will create a symlink, assuming that their
> native windows app will be able to use it but, will get a strange error
> when they attempt to run the program. With the fallback there will be
> no way to test, within cygwin at least, what format the symlink is and
> so they won't even be able to verify that the symlink is what they want
> it to be.
> I don't feel strongly about this but I thought that the fallback behavior
> could be confusing to the end user.
I agree with Chris on this. Instead of a fallback behavior it should
be an EACCES, EINVAL or EXDEV error.
More information about the Cygwin-developers