Message-ID: <46CADFAC.4010209@byu.net>
Date: Tue, 21 Aug 2007 06:50:52 -0600
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: symbolic link untar issue
References: <200708202358 DOT l7KNwl7b025934 AT tigris DOT pounder DOT sol DOT net>
In-Reply-To: <200708202358.l7KNwl7b025934@tigris.pounder.sol.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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

According to Tom Rodman on 8/20/2007 5:58 PM:
> These steps 'hide bash', so invoking bash again fails:
> 
>   /tmp $ uname -a
>   CYGWIN_NT-5.0 argon 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin
>   /tmp $ tar tvf bar.tar
>   drwxrwxr-x staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/
>   lrwxrwxrwx staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/bash2 -> /bin/bash
>   /tmp $ tar xpf bar.tar; tar xpf bar.tar #2nd untar does the damage

It looks like tar is trying to follow the symlink, and touches what the
symlink points to (I'm not sure why tar is insisting on following the
link; that may be an upstream bug).  Anyway, since the symlink was created
without pointing to the .exe extension, tar is thus getting confused
between touching bash.exe and creating bash with no extension.

This seems like a corner case, so I'm not sure how much time I will spend
trying to work around it, but thanks for reporting it.  On the other hand,
since tar files created on platforms without .exe suffixes are likely to
look like this, maybe I should at least investigate making tar smarter
about extraction of links.

> 
> Is that an old style cygwin snybolic link?  If so how do I identify all of them,
> so I might update them on my system?

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:

$ ln -s /bin/bash bash2
$ readlink bash2
/bin/bash.exe

Therefore, if you are worried about the existence of symlinks whose
contents leave out the .exe suffix, you could do something like the
following to find candidate links that might need correction:

$ find [directory] -maxdepth 1 -type l \( -lname '*[^.][^e][^x][^e]' -o
- -lname '???' -o -lname '??' -o -lname '?' \) -print

Beyond that, there are probably ways to automate replacing the broken
contents of such links with automatic .exe suffixes where appropriate,
once you realize that this idiom will make the conversion:

$ ln -fs "$(readlink "./bash2")" "./bash2"

> Cleanup.., how to delete the zero byte '/bin/bash':
> 
>   /tmp/ZZ $ (cd /bin ; chmod 777 bash;cmd /c del bash; ls -l bash)

Yuck.  Why rely on cmd?  It is simpler to 'rm bash', which will delete the
non-suffix version without touching the .exe version.  Also, it is not
necessary to chmod 777 the empty file; you can delete files with 0
permissions (although you may have to answer an interactive question to do
so).

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

Eric Blake             ebb9 AT byu DOT net
volunteer cygwin tar maintainer
-----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

iD8DBQFGyt+s84KuGfSFAYARAn9tAJ4iiVlckqAdtqMl2TR3M47/jZPecQCcDsuD
RprFDP9Stc/3qAMvWmqgR8Y=
=ecVY
-----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/