Re: native symlink

[James Gregurich <bayoubengal at mac dot com>]

On Mar 27, 2013, at 3:41 PM, Larry Hall (Cygwin Developers) <lhall@cygwin.com> wrote:

> On 3/27/2013 5:53 PM, James Gregurich wrote:
>> Why don't you add an API call and utility to actually convert an existing  > cygwin symlink into a native symlink. I'll give you code that does the work.
>> Cygwin already reads and uses the native symlinks. you might as well provide
>> a way to create them.
> 
> The main list is really the right place to make Cygwin feature requests.

I'm using this list because this is where I found the original debate on the subject. I wanted to add my voice.


> Patches to the DLL can go to cygwin-patches.  Other code can go to the
> main list as well.
> 
> As for why this hasn't been done before, some of it is just no one has
> done it.  

I have. I am actively using a version of cygwin with a modified DLL that implements use of native symlinks. I've previously described the work I've done. I've offered up my code. I never really got rational, technical reasons for why such support was a bad idea.



> But perhaps more importantly is the question of the benefit.

Here is a benefit…

My company maintains  cross-platform source code and and binary  library git repositories. These repositories heavily use symlinks to organize the files so that redundancies are minimized and libraries are presented in representations that allow clean integration with both Xcode and Visual Studio across multiple projects and developers' workflows. Since my version of cygwin properly sets up native symlinks, it all works cleanly with Visual Studio, Windows Explorer and every other Windows development tool I've worked with. The standard version of Cygwin does not produce repositories that work with Windows developer tools if those repositories contain symlinks.

I have given up on the possibly of Cygwin's developers supporting the modifying of the posix symlink() function (as I did) to create native symlinks when possible. However, my usage case is still accomplishable with just the ability to convert Cygwin symlinks to native symlinks after the fact through a separate utility and corresponding posix-level API call. So, now I shall lobby for that instead.




> There are (non-Cygwin) tools already that support this.  Also, since
> native symlinks only work on NTFS, providing a utility to create them
> opens us up to bug reports and questions about these limitations.  In
> addition, there will be questions about why yet another "symlink"
> utility exists and when should it be used.  But if you want to argue
> for such a tool, please review the previous discussions in the email
> archives (to make sure you're not covering the same ground again) and
> bring up your proposal on the main list.  Be prepared for a fight
> (ah, "robust discussion" ;-) ) though.


Frankly, I've never understood the arguments presented. As I said in the past, you ALREADY read native symlinks. Much if not all of the technical consternation I've seen discussed on the subject already exists in what you have today. Since you already READ the symlinks, surely it makes sense to offer more complete interoperability. Is not the purpose of Cygwin to allow unix software to interoperate with a Windows environment? Is not its purpose to allow useful work to be done on Windows using unix software? 

If you are going to limit yourself to features that won't cause reactions and objections, then exactly how to you plan to make progress?  ANY change disrupts someone. ANY change is going to cause tech support tickets. I'm sure these 64 bit changes that are being described will inconvenience someone out there, yet it needs to be done to keep up with the times.


That said…..

What I am lobbying for is not to rework the core symlink mechanism as I have suggested in the past. All I am lobbying for is a new symlink API call and a corresponding command line utility to convert an existing cygwin symlink to a native symlink if it is possible. I don't see how adding that ability would disrupt anyone or cause tech support headaches. People like me who need native symlinks can use this new functionality. Since we will already understand the limitations of native symlinks, we won't be likely to file tech support tickets frivolously. People who don't need native symlinks can safely ignore the new utility and API call.

Even the details of the code is worked out already. The code I have would just need to be massaged into a little different form. 


-James