This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: native symlink


On Mon, Apr 01, 2013 at 03:02:50PM -0700, James Gregurich wrote:
>
>On Apr 1, 2013, at 12:52 PM, Christopher Faylor <cgf-use-the-mailinglist-please@cygwin.com> wrote:
>
>> 
>> If you're referring to this:
>> http://sourceware.org/ml/cygwin-developers/2012-12/msg00000.html
>> 
>> Then I did respond later in the thread.  So, please don't claim that
>> I'm irrational or nontechnical.
>> 
>> To summarize my objection:  It doesn't sound like the native symlink
>> can be made to completely emulate a Linux symlink.  That has always
>> been the problem with Windows symlinks.
>
>
>As I said before (and this is discussion of technical detail for
>programmers), it doesn't need to fully emulate a unix symlink.  The
>design I proposed would attempt a native symlink and then fall back to
>normal symlink if the operation failed.  The posix layer doesn't care
>which physical form the symlink takes.  it works the same either way.
>The mechanism works nicely...I have prototyped it.

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.

>>> 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.

>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.

>...
>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.

>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.

>>However, if you think it's a great idea to have a utility which does
>>stuff to and with native symlinks then that's something that you could
>>write yourself and propose to be included in the Cygwin distribution.
>>That would be something you could discuss in the cygwin mailing list
>>and, ultimately, the cygwin-apps mailing list.
>
>
>I did write the utility myself?.as I have said repeatedly.

You mentioned in your original mail that you'd written some utilities
but those appeared to be using the changes that you'd made to Cygwin.  I
was suggesting that you could just write a utility which didn't use a
Cygwin API to create a symlink.  Since you said:

'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.'

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.

>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.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]