This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: native symlink support should fallback to default format if target missing
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 13 May 2013 14:59:37 -0400
- Subject: Re: native symlink support should fallback to default format if target missing
- References: <517F061D dot 5080201 at cygwin dot com> <671E245A-BDCD-4F46-90B7-9E73301126C1 at mac dot com> <20130430002548 dot GA7635 at ednor dot casa dot cgf dot cx> <9FCBD602-2D9C-4069-AA5F-682C32DE6D32 at mac dot com> <517F13D1 dot 8040105 at cwilson dot fastmail dot fm> <B225793A-09C6-4E2C-B257-5A7FAF7E990E at mac dot com> <56151889-406D-4648-BFC9-BEE3AE70D56E at mac dot com> <20130513150046 dot GB20319 at calimero dot vinschen dot de> <519105F5 dot 2080101 at openafs dot org> <20130513154007 dot GE8890 at calimero dot vinschen dot de>
- Reply-to: cygwin-developers at cygwin dot com
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.
>>
>> Corinna,
>>
>> 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.
cgf