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: Jeffrey Altman <jaltman at openafs dot org>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 14 May 2013 11:54:50 -0400
- Subject: Re: native symlink support should fallback to default format if target missing
- References: <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> <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>
- Reply-to: jaltman at openafs dot org
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.
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.
I believe the above behavior is a different mode than
"winsymlinks:native". Perhaps "winsymlinks:native-preferred".
Jeffrey Altman