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 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


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