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: Tue, 14 May 2013 12:42:09 -0400
- Subject: Re: native symlink support should fallback to default format if target missing
- References: <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> <CA+sc5mkQEQe0CyagMqyzH2i2A1KtAk4fJwr=v_y0+RrcXqNv7A at mail dot gmail dot com> <4A874440-F98D-4CC2-B6BB-F8D04CF99266 at mac dot com> <20130514150435 dot GD23910 at calimero dot vinschen dot de> <51925E4A dot 4000302 at openafs dot org>
- Reply-to: cygwin-developers at cygwin dot com
On Tue, May 14, 2013 at 11:54:50AM -0400, Jeffrey Altman wrote:
>On 5/14/2013 11:04 AM, Corinna Vinschen wrote:
>> 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
>
>I definitely see Christopher's point and I am very sympathetic to it as
>someone that has to support a large anonymous user community. Provide
>rope but not enough to permit the user to hang themselves from the
>perspective of losing data through a lack of understanding of a how a
>feature works.
>
>I suspect the behavior that James really wants is the following:
>
> 1. if the target of a symlink exists and the underlying file system
> supports symlink reparse points, create a symlink reparse point.
>
> 2. if underlying file system doesn't support symlink reparse points,
> generate an error.
>
> 3. if the target of a symlink doesn't exist, create a cygwin
> symlink as a place holder.
I see 2. and 3. as basically the same thing. By the logic advanced
here it seems like, for consistency, 2. should silently create a
cygwin symlink. I don't think that's a good idea but I do think it
would at least be consistent.
> 4. if a cygwin symlink is accessed and the target exists and the
> file system supports symlink reparse points, replace the cygwin
> symlink with the symlink reparse point.
Ugh. Please no. Silently modifying the filesystem is rather surprising
behavior. It gives the user no control.
cgf