Message-ID: <461A3A14.8090702@byu.net>
Date: Mon, 09 Apr 2007 07:05:24 -0600
From: Eric Blake <ebb9@byu.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: ln -s exe magic (coreutils 6.7-2)
References: <011701c73f43$3d07d270$3e0010ac@wirelessworld.airvananet.com> <20070124043651.GF25379@ns1.anodized.com> <20070124094810.GN27843@calimero.vinschen.de> <45B76311.1000009@byu.net> <20070124143821.GQ27843@calimero.vinschen.de>
In-Reply-To: <20070124143821.GQ27843@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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