native symlink

James Gregurich
Wed Apr 3 03:16:00 GMT 2013

On Apr 2, 2013, at 6:40 PM, Christopher Faylor wrote:

> So, sometimes people would find that their windows programs would fall
> over when accessing a symlink.  That's not a tech support email I'm
> interested in handling.

(keep in mind that on this point we are discussing a hypothetical since I am no longer asking for symlink() to be modified.)

How many support emails do you think you would get for a failure to create a relative path symlink where the path exceeds 254 (if memory serves me correctly) chars? Its a pretty rare circumstance.

Secondly, the support for native symlinks is off by default and would only be enabled by someone who actually wants that functionality.  That person would have been provided documentation for the use of the feature that he would have had to reference to understand how to enable the feature in the first place. So, these things could be documented.

Why are you so worried about theoretical tech support tickets that may never happen in the real world? 

My team supports a pretty good size matrix of commercial products that people use for real-world, for-profit, production work. We certainly don't avoid taking risks on useful features. We are careful and thoughtful about it and make every effort to make sure we don't break existing functionality, but evolving our software is our reason to exist. If we get support emails coming in…we deal with them! that is our job. I really don't get this fear of getting support tickets. 

>> Yes. I did answer your objections. You never responded. 
> I posted, in a previous message, the link to the discussion from back in
> December.  My response was the last one in the archives.

I never saw a response. Perhaps I missed it in my email box for whatever reason. Its not worth going back through the logs to find out for sure. I'll just take your word for it and drop the point.

>> Why is adding a couple extra data members to your existing classes
>> considered a significant amount of complexity increase?
> You can be sure that since I didn't use the term "data members" I was
> talking about all of the lines of code that you posted.

With the exception of the data members, all of my new code is factored off by itself.  That is the only part that is intermingled with existing code. Thus, the labyrinth is almost entirely unaffected. 

I took on your code in all its complexity knowing nothing about it or its design. I'm not even primarily a Windows developer. I'm a mac developer. Yet, i worked my way through it all, figured out everything I needed to figure out and made it all work. While the code certainly could be better designed and would be benefitted by some modern C++ practices, it certainly wasn't impossible to understand or modify it. I'll admit it is fairly hairy, but I've seen much worse in my life. 

Why am I unafraid to dig into your code and extend it, but you (who should know it better than I do) are so afraid to extend it? I invested a couple of months in these modifications given I had a ton of research and experimentation to do. That is tens of thousands of dollars of engineering time my company risked to make a useful tool. I'm really quite puzzled by this fear to modify the code.

>>>> 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
>> ... my suggestion is not a significant increase in complexity.
> Sorry, but I think that, given the cost/benefit of this change, 129
> lines of code in a sensitive data path + extra data members in a
> structure is significant.  If this change added full handling of Windows
> symlinks with no compromises, that would be a different story.

There are not 129 lines of code in a "sensitive data path."  There is a couple of data members and associated accessor functions. That's it. Why do you insist on imagining that there is more to it than there is?

Secondly, maybe there is no "benefit" to YOU.  But, to those of us who need unix repositories to work on Windows and Visual Studio, there is a HUGE benefit. I suspect I'm not the only guy out there who needs the functionality. I've gotten a couple of private emails from people who want the functionality. I know there is an ongoing effort on MSYS-GIT to make it work with native symlinks on Windows. There are people who use this. 

thirdly, what is the "cost" to you? I've done the heavy lifting. We use the code in production.  It works. I haven't had to go back and fix any bugs in it since I deployed it. Granted, we are a small operation. But we do hit it with developer tools and various unix programs. It has never failed or exhibited weird behavior that could be attributed to my changes.

Is your "cost" some number of support tickets that may never happen? If not, please explicitly list the "costs" that you envision besides support tickets.

>> 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
> We try hard not to add non-Linux interfaces to Cygwin.  IIRC, we haven't
> done anything like that in years.  And, neither Corinna nor I want to do
> that for this case.

Is cygwin_conv_to_win32_path() a "Linux interface"? You already provide functions in the posix fact, in itself... to help integrate the unix environment into Windows better.

The purpose of cygwin is to integrate unix software with a Windows environment. If a person just wants to run unix software on a pure Linux interface, he can just run Linux. He doesn't need Cygwin. There is minimal purpose to Cygwin if all it is intended to be is just Linux on top the NT kernel.

What is the practical purpose to this rule you have made to not add "non-Linux interfaces" to Cygwin? That seems silly given the purpose of the project is to make Windows more useful.

>> Secondly, exposing an API call would enable people to programmatically
>> use the functionality from any application without an additional
>> library to worry about.
> Every API doesn't have to come from Cygwin.  You can always add a library
> to a Cygwin package and instruct people to use that if they want to roll
> their own.

Should I write my own code to do all the path parsing and processing that is already done in Particularly since I've already coded al the work to the classes in That makes no technical sense. All of this work is already done in 

> I only cut part of Daniel's message but what he was saying was that
> the Cygwin developers think that symbolic links work well enough.  The
> "Cygwin developers" part is the important part.

If the purpose is just to please this narrow of a demographic of potential users, why bother making it open source…or even making it public at all.

Perhaps Cygwin's developers should widen their scope and perspective if they want to attract more users.

> FWIW, the reason that we didn't think that 260 characters was "good
> enough" is because Linux doesn't have such a limit and it was, for the
> most part, possible to make longer pathnames work without compromise.
> Your approach, on the other hand, can't be a complete replacement for
> Cygwin symlinks.  So, it's not really an apples-to-apples comparison.

And yet that mechanism is imperfect in that it cannot handle relative paths. But, you implemented it anyway.

> You're really pulling out all of the stops.

Persistence and doggedness are useful virtues. :)

One needs these traits to get things done…PARTICULARLY when dealing with engineers.

> Since you asked, the major motivation behind 64-bit Cygwin is that
> someone at Red Hat thought it would make financial sense to finally port
> Cygwin to 64-bit.  And, now all of the package maintainers are willing
> to do the work to get onto a new platform.  Everyone will benefit from a
> 64-bit Cygwin.  It's a clear win.

I don't benefit from it. 32 bit Cygwin works fine for me. I'd be willing to bet that the people who actually need a 64 bit cygwin are a very small percentage of the user base. The only reason you need a 64 bit process is for perhaps a little better performance for some problems due to extra registers on x86_64 and access to more than 2 GB of memory per process. Frankly, anybody who has serious needs for those two things is unlikely to be running such processes on Cygwin when he can just run it on *nix where he gets a much more reliable and predictable runtime. 

But, I can certainly appreciate that you did it for money. Also, it should have been done to keep up with the times if nothing else. I'm just making the point that a useful feature should not be denied just because you personally don't need it. You need to think of your customers.

>> 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.
> There *is* a cost to me or Corinna here.  We'd have to carefully review
> your 129 lines of code and be involved in the back and forth that
> entails.  And, then we'd eventually have to support the proposed code,
> respond to bug reports on it, and make sure that it was properly
> documented.  And, since neither of us is keen on this approach that's
> more than we're willing to do.

But then you would also gain access to an additional development resource who will have demonstrated that he can competently operate in to get useful work done. I certainly would not petition to add the feature and then not make myself available to help out in supporting the project.

Perhaps you didn't count that as a "benefit."

>> If I have the support of the programmers, then I'll go through the
>> necessary bureaucratic rigamarole to get the changes adopted.
> Thanks for the offer of a patch but this is not something that we are
> willing to add to the code.  And, we are not interested in adding a new
> non-POSIX/linux API to Cygwin for manipulating native windows symlinks.

I've think I've demonstrated that this is a statement of dogma and personal preference…not technical substance.

You already have "non-posix/non-Linux" API calls in Cygwin.dll and There is absolutely no technical reason to have a rule not to add more as long it is done thoughtfully and carefully. You've already shown that you will add features (64 bit support) that few people actually need. Finally, you have shown with extended path names that you will implement features that are imperfect solutions if they are useful. I think those three answers shoot down your technical objections.

The only non-technical objection you've made is that it will theoretically create support tickets…But as I said…you are likely to get way more support tickets on things you broke adding 64 bit support than you would from this feature. If you are really concerned about support tickets, you would have not make the 64 bit changes.

More information about the Cygwin-developers mailing list