native symlink

James Gregurich
Wed Apr 3 21:31:00 GMT 2013

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.

More information about the Cygwin-developers mailing list