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: ln -s exe magic (coreutils 6.7-2)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Revisiting an old thread...

According to Corinna Vinschen on 1/24/2007 7:38 AM:
> On Jan 24 06:45, Eric Blake wrote:
>> According to Corinna Vinschen on 1/24/2007 2:48 AM:
>>> This looks rather like a problem with the exe magic in coreutils.  FWIW,
>>> I never liked the idea to create "foo.exe.lnk" symlinks.  They only slow
>>> down the symlink processing in Cygwin.
>> Should we get rid of the special processing in cygwin 1.7.0?
>> [...]
>> I'm having a tough time thinking of any scenarios that will break in a new
>> installation if we drop .exe.lnk support; and I'm only slightly worried
>> that existing cases, such as Pierre's example of /usr/sbin/sendmail.lnk
>> vs. /usr/sbin/sendmail.exe.lnk, tripping up users.  I would be in favor of
> 
> I appreciate the idea to remove it, but I have long ago already
> convinced myself that we will have problems removing it.  A quick look
> into /bin on my machine, which has basically a standard install of
> roughly 30-40% of the available packages in the distro, shows that
> existing installs have a non-marginal number of .exe.lnk files:
> 
> $ find /bin -type l | grep \\.exe
> /bin/awk.exe
> /bin/c++.exe
...

I'm working on preparing the coreutils 6.9 release, and want to improve
symlink handling in the process.

I'm thinking that for the original bug:
$ ln -s -f /usr/bin/exim /usr/sbin/sendmail
$ ln -s -f /usr/sbin/ssmtp /usr/sbin/sendmail
$ ls -l sendmail*
lrwxrwxrwx 1 p-humblet sw 13 Jan 23 17:40 sendmail -> /usr/bin/exim*
lrwxrwxrwx 1 p-humblet sw 19 Jan 23 17:29 sendmail.exe -> /usr/sbin/ssmtp.exe*

when creating symlinks, I plan to still auto-append the .exe to the link
target if necessary (otherwise, exec*() succeeds but open() fails when
dereferencing the symlink), but not to the link name.

Therefore, in the original case, the first ln -s generates
sendmail->/usr/bin/exim, then the second ln -s overwrites it with
sendmail->/usr/sbin/ssmtp.exe rather than adding a new file.

Now, should I also make ln -s smart enough for the reverse?  In other
words, if sendmail.exe->/usr/sbin/ssmtp.exe exists, and the user does 'ln
- -fs /usr/bin/exim sendmail', should I delete the existing sendmail.exe.lnk
as part of creating the new symlink?  I'm guessing that since the -f
implies unlinking first, that this would be okay to do.

The other thing I am thinking about is making the coreutils postinstall
script go through /usr/bin and finding all instances of *.exe.lnk, and
rewriting those symlinks to be just *.lnk, taking care of Corinna's list
of symlinks with .exe in their name.  This won't catch everything, but it
will be a good chunk of the current issues, while transitioning towards
the point of preferring only *.lnk rather than *.exe.lnk for a symlink
name.  I wonder, though, if this will trip up cygcheck at all.

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

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGGjoU84KuGfSFAYARAsubAKCQhA1Vdgtu2LBooo7YSHnhDccBzwCgln+h
76psqeqGLWHC+Malt2CRXnI=
=exaI
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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