This is the mail archive of the cygwin 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: symbolic link untar issue

Hash: SHA1

According to Eric Backus on 8/24/2007 2:24 PM:
> Eric Blake <ebb9 <at>> writes:
>> No, it is not an old-style link, because it has the .lnk suffix when
>> viewed via Windows.  However, it is not a link that would normally be
>> created by the current coreutils, since I have added some .exe magic into
>> ln when symlinking against existing .exes:
>>From this I guess that the .exe magic is currently in the code for each 
> program that might create a symlink.  Is there any way that the .exe magic 
> could be moved to inside the symlink() function call, so that it automatically 
> works for all programs that create symlinks?  Or does that introduce other 
> problems?

Most .exe magic is already inside cygwin.  In particular, CVS cygwin
(which will become 1.7.0) has a transparent_exe option that makes this all
even cleaner, without application specific knowledge.  Coreutils is
special, in that it tends to do a lot of low-level tasks where the .exe
magic provided by cygwin is not always smart enough (for example, cp
/bin/bash /bin/sh needs to add .exe), at the expense of making usage
patterns of more common upper-level applications do the right thing by

But the real problem reported by this thread has nothing to do with .exe
magic after all.  Rather, it had to do with a non-compliant implementation
of open(O_CREAT|O_EXCL).  In other words, to date, I have not had to teach
tar about any special .exe magic.

- --
Don't work too hard, make some time for fun as well!

Eric Blake   
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

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