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: Earnie Boyd <earnie at users dot sourceforge dot net>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 13 May 2013 15:47:42 -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> <20130513185937 dot GA1601 at ednor dot casa dot cgf dot cx>
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.
>>>
>>> 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.
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