Re: symbolic link untar issue
Eric Blake byu.net> writes: > 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. > > 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). Ah. OK, thanks for the update, and all your hard work. -- Eric -- 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/
Re: symbolic link untar issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Backus on 8/24/2007 2:24 PM: > Eric Blake byu.net> 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 default. 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 [EMAIL PROTECTED] -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 iD8DBQFGz0Qw84KuGfSFAYARAsWnAKDY0PFvT83HjLYsNVd89GE9Bkm3zwCgmUIn fOJklfUULT+2gqYlY1nkRCI= =/SPe -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/
Re: symbolic link untar issue
Eric Blake byu.net> 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? -- Eric Backus -- 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/
Re: symbolic link untar issue
-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 [EMAIL PROTECTED] 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/
symbolic link untar issue
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 /tmp $ ls -l /bin/bash -- 1 adm_usr1 None 0 Aug 20 18:03 /bin/bash /tmp $ ls -l /bin/bash.exe -rwxrwxrwx 1 Administrator Users 470528 May 1 21:22 /bin/bash.exe* /tmp $ bash -bash: /usr/bin/bash: Permission denied Notice the zero byte file '/bin/bash' w/o any perms; it causes subsequent invocations of bash to fail. It is the 2nd untar that does it. Here's what is in 'bar.tar' ( which is also attached ): /tmp/ZZ $ md5sum /tmp/bar.tar 0a3b22f3e6d00c68f7000b4fc1b80993 */tmp/bar.tar /tmp $ cd ZZ /tmp/ZZ $ cmd /c dir Volume in drive D has no label. Volume Serial Number is BC28-E542 Directory of d:\aut\cyg\tmp\ZZ 08/20/2007 05:29p. 08/20/2007 05:29p.. 08/20/2007 06:03p 108 bash2.lnk 1 File(s)108 bytes 2 Dir(s) 544,944,128 bytes free /tmp/ZZ $ cmd /c type bash2.lnk|command od -Ad -c 000 L \0 \0 \0 001 024 002 \0 \0 \0 \0 \0 300 \0 \0 \0 016 \0 \0 \0 F \f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 032 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 048 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 064 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \t \0 / b 080 i n / b a s h 023 \0 d : \ a u t \ 096 c y g \ b i n \ b a s h 108 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? -- thanks, Tom Rodman -- Cleanup.., how to delete the zero byte '/bin/bash': /tmp/ZZ $ (cd /bin ; chmod 777 bash;cmd /c del bash; ls -l bash) -rwxrwxrwx 1 Administrator Users 470528 May 1 21:22 bash* -- bar.tar.gz Description: Binary data -- 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/
