This is the mail archive of the
mailing list for the Cygwin project.
Re: Native symlinks and setup.exe
Never mind, I found it's in another repository.
The code looks quite different, adapting the symlink code from newlib
to setup doesn't look straightforward, at least to my limited C
By the way, if I have an already created symlink, how do I check (e.g.
in a bash script) whether it's native or cygsymlink?
On 5 October 2016 at 02:08, Gene Pavlovsky <email@example.com> wrote:
> Before writing a patch it's wise to check if it would be accepted, now
> that your position is clear, somebody might do it.
> I don't think I'm up for the task, but I'd like to at least take a
> look at the sources.
> I've downloaded the git sources and found the link creation function
> is in winsup/cygwin/path.cc, can you tell me where are the sources for
> the setup util?
> On 5 October 2016 at 00:04, Eric Blake <firstname.lastname@example.org> wrote:
>> On 10/04/2016 03:53 PM, Vince Rice wrote:
>>>>> Obviously, a political discussion is required, to decide whether it is
>>>>> ok, as is, or if a change in package logic would have benefits.
>> The easiest way to have the discussion would be to write a patch,
>> instead of debating about different behaviors but then expecting others
>> to do the work.
>>> I don’t see that changing. And, as already noted, setup isn’t a Cygwin program,
>>> so it knows (and cares) nothing about cygwin environment variables.
>> setup.exe has its own untar'ing code (it is NOT forking tar, since one
>> of the packages setup.exe has to install is tar, and it would be a
>> chicken-and-egg problem if setup always forked out to a tar program if
>> it can't first untar the tarball containing tar). But while setup.exe
>> apparently does NOT currently honor the CYGWIN environment variable with
>> regards to how its untar'ring code should behave on symlinks, there's
>> nothing that prevents you from writing a patch to teach it to do so, and
>> perhaps that patch can even share some of the existing code for
>> cygwin1.dll so that you aren't writing it from scratch. It should
>> already be clear that code exists in setup.exe that handles symlinks in
>> tarballs - all that this thread is complaining about is that the code
>> doesn't do it the way that cygwin1.dll does it. But someone has to
>> write such a patch, and preferably someone that cares enough to be
>> bothered by the current behavior (I don't, so it won't be me writing it).
>> Eric Blake eblake redhat com +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple