This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: native symlink
- From: James Gregurich <bayoubengal at mac dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 03 Apr 2013 14:31:32 -0700
- Subject: Re: native symlink
- References: <80C3E267-F369-4FF3-A3FD-69A997FFC33B at mac dot com> <5153759A dot 7080307 at cygwin dot com> <79518574-72AB-451F-ACE3-3277981987D5 at mac dot com> <20130401195216 dot GA7174 at ednor dot casa dot cgf dot cx> <9A868E84-96C2-486C-98DF-3FF5079ACD50 at mac dot com> <20130402000633 dot GA3977 at ednor dot casa dot cgf dot cx> <9362C76C-DB6B-4DA8-B61E-7980CFDF7A8A at mac dot com> <20130403014056 dot GA3383 at ednor dot casa dot cgf dot cx> <2EC5409B-C507-4B41-862C-D42D69CE3741 at mac dot com> <515BB10C dot 9080101 at openafs dot org> <20130403152907 dot GD2468 at calimero dot vinschen dot de>
On Apr 3, 2013, at 8:29 AM, Corinna Vinschen wrote:
>
>
> There are some downsides to native symlinks which make them hard to
> justify, if not downright useless in a POSIX environment.
>
We all understand the limitations and we grant you that. That is why I have proposed an add-on feature rather than an augmentation of the symlink() function. Add an additional API call in the spirit of existing functions such as cygwin_conv_path_list() that will allow an existing cygwin symlink to be replaced by a native symlink. Those who need native symlinks can use that function call. As an add-on, optional API call, he function can accept flags that allow the user to choose how to handle non-optimal situations such as relative paths that exceed PATH_MAX, and it can return error codes that indicate exactly why a native symlink failed to be produced. This way, there is no ambiguity that can generate support tickets.
>> As I see it, as flawed as Microsoft Symlinks are they are the common
>> interface that enables mixed applications to communicate with one
>> another. As such, where they can be used, they should be used. What is
>> the point of cross-platform support if mixed platform applications
>> cannot transparently share the data?
>
> Cygwin is a POSIX environment in the first place. Interop is fine,
> but if it collides with POSIX, we're clearly favoring POSIX.
I'm suggesting an approach that does not conflict with posix. However, I don't know if that concept works for Jeffery or not.
> Having said that.
>
> Chris and I had a private discussion (not the first one on the subject!)
> and we're willing to revisit the use of native symlinks in Cygwin but
> it will be a while before that happens. A change to the path handling
> code like this is not something that we'd consider for 1.7.18 which is
> long overdue anyway.
fair enough. If its on the radar, I'm happy. What I have should be functional for a long time. Like I said, I can contribute my code that you can use as a guide.
>
> What I will do is to add a new CYGWIN environment variable option, along
> the lines of the winsymlinks option(*), or, which is very likely the
> more elgant solution, a mount option, which will result in trying to
> create native symlinks first, and a Cygwin symlink only if creating
> a native symlink failed. That should help you along.
If you want to go all the way, that works for me too.