native symlink

James Gregurich bayoubengal@mac.com
Wed Apr 3 00:49:00 GMT 2013


[resent from sourceware spam trap by cgf]
On Apr 1, 2013, at 5:06 PM, Christopher Faylor wrote:

> 
> In the model that you originally proposed, a fallback wouldn't be
> sufficient.  As described, you were creating symlinks with absolute
> paths and those won't fly.

That isn't a problem. This only happens in the case where the path exceed PATH_MAX. In that case, instead of invoking the logic to contrive the extended path name, just abort the effort and fall back to the default symlink.



> 
>>>> What I am lobbying for...
>>> 
>>> As Larry indicated, this is not the mailing list for "lobbying"
>>> however, to save you the trouble of moving to the cygwin mailing list:
>>> As I (and Corinna) have said before, I'd rather not complicate the
>>> labyrinthian path handling code by introducing a new API.  I don't
>>> really see why one would be needed.
>> 
>> This is why I already throw around words like "irrational." I have said
>> multiple times that you already read native symlinks.  Your
>> "labyrinthian" code already codes does it.  Nothing needs to be added
>> to your labyrinthian code for handling paths.  But, it seems like this
>> sentence always gets piped right to /dev/null for some reason.  That
>> point never gets acknowledged.  The same argument just gets repeated
>> over and over despite the fact that it has been answered.  To me, that
>> is not rational thinking.  sorry.
> 
> As far as I can see, you posted two messages to this mailing list.  I
> responded to one of them.  You didn't, as far as I could see, respond to
> my message which offered (despite your words to the contrary) technical
> objections.

Yes. I did answer your objections. You never responded. 




> 
>> In fact, let me document for you exactly what I changed in your
>> labyrinthian path handling code?
> 
> I count 76 lines of code there, total.  I don't know if this code
> addressed my technical concerns but I suspect that it doesn't.

The purpose of supplying those snippets was to establish that my suggestion would not deepen the labyrinth. If you would like to see the entirety of what I did to path.cc, I can certainly supply that by whatever communication channel you prefer. Just let me know.




> 
>> ...
>> Basically, the only modification I did to the existing labyrinthian
>> path handling code was to store some extra data I needed make decisions
>> in my new code higher up in the code stack.  That's it! Now, I hardly
>> think these changes constitute a significant increase in the complexity
>> of the existing path and symlink reading code.
> 
> I probably didn't make my point clear.  Adding any amount of code to the
> path handling is something that we try to avoid but I do think that your
> additions add more complexity than I'd be comfortable with, especially
> given the limitations of Windows symlinks.

Why is adding a couple extra data members to your existing classes considered a significant amount of complexity increase?


> 
>> So what exactly did I change to implement creation of native symlinks
>> (the actual new functionality?  ?
> 
> So that's another 53 lines to the path handling code.  That brings the
> total to about 129 lines added/changed.

yes.  That constitutes the limits of my changes to the existing path.cc.   That is why I keep telling you that my suggestion is not a significant increase in complexity. If you take out my changes to symlink_worker() and just supply an additional API call to convert the symlink after the fact, then the changes to existing code are negligible. One would just need to append a few functions that don't do anything more with the existing path logic other than access the new data members.

I don't see reason for consternation here.


> 
> I was trying to tell you that you could just propose packaging a new
> Cygwin utility to create the symlinks that you claim Cygwin already
> reads.

path.cc already contains all of the logic necessary to make all the decisions necessary to convert a cygwin symlink into native symlink. Why would one want to reimplement all of that in a client application? It makes perfect sense for that logic to exist in path.cc.

Secondly, exposing an API call would enable people to programmatically use the functionality from any application without an additional library to worry about.





> 
>> I'm certainly willing to join this other mailing list and make a formal
>> proposal.  But, I don't want to waste my time if the programmers don't
>> want to be bothered.  So the question is?  have I made my case
>> sufficiently so that the programmers will be willing to work with me?
> 
> I'm not interested but, if Corinna thought this was must-have
> functionality, I would certainly not block any code additions to Cygwin.
> 
> I suspect that what Dan Colascione said back in 2012-12-08 is still
> true, though:
> 
> "Cygwin symbolic links work well enough, and I don't think trying to
> overcome these difficulties is a high priority."
> 
> However, A utility which made no changes to the DLL but just got
> packaged up with the rest of the Cygwin distro wouldn't require any
> programmers besides yourself.  You'd just have to take it through the
> Cygwin package adoption process and get the requisite number of votes.


"work well enough" is in the eye of the beholder.  Cygwin is worthless to my purpose without proper support for native symlinks. Native symlinks are critical to the design of our git repositories and well cygwin  shell scripts we write as part of our Visual Studio workflow.

There are two reasons why I went with cygwin over MSYS-git for our purpose…

1) Cygwin already supported extended path names. 
2) The source code and design of Cygwin were sufficiently straight-forward that I could modify it to add the symlink support I needed.


So, if some developer of Cygwin had decided that 260 character path names was "good enough," then I wouldn't have had #1 and perhaps I would have sought out some other solution. Perhaps one should not be so short-sighted as to what constitutes "work well enough" if he wants to attract additional users to his platform.

Did not Cygwin also "work well enough" as a 32 bit process? Why bother with 64 bit support if this is the attitude?  I bet the modifications to support 64 bit usage cost far more in time, complexity and support tickets than my suggestion would. Why dismiss my suggestion out of hand just because you don't personally need it? 

I certainly have not suggested someone do the work for me. I've done the work for you and am offering it up at no cost to you other than to cooperate with integrating it into the system. I've even acknowledged that I might have to spend some time modifying the work to meet requirements I'm unaware of.


If I have the support of the programmers, then I'll go through the necessary bureaucratic rigamarole to get the changes adopted. 












More information about the Cygwin-developers mailing list