Joerg Schilling <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: > >> If tar is run in the following manner: >> - in --create mode, with a named target (i.e., not stdout), >> - with stderr closed, and >> - in a way that provokes tar to write a diagnostic, >> then tar corrupts the named output archive by writing the diagnostic it. >> >> Here's a demo: >> >> $ rm -rf a; mkdir -p a/b; chmod 0 a/b; tar cf x.tar a 2>&-; \ >> head -c39 x.tar|grep tar: ; chmod -R 700 a; rm -rf a >> tar: a: Cannot open: Permission denied >> >> That shows that the first line of the created archive, x.tar, >> is tar's own diagnostic. > > Besides the fact that "head -c39 x.tar" is illegal ans will cause this > error message: head: Ungültige Option -- c > > It needs to be "head -39c x.tar"...
Oh, I see. `head -c39' works fine with GNU head, so you must be using some other version. I agree that using -39c is more portable. > What you see is definitely not a GNU tar bug - it happens with every tar > implementation (except star in default mode that forks, creates a FIFO > and a pipe that will get fd#2 and close it in the tar process... with > star -no-fifo .... you get the same). > > What you describe is not a bug in GNU tar (or any tar) but it is a result > of "what you see is what you told sh...". In my book, any program that corrupts its output file because you've close-at-startup some unrelated stream is buggy. Just because most other versions of tar fail that way doesn't make it unavoidable or otherwise acceptable. The bug is that tar assumed open/creat would never return 2. The patch I supplied shows that this bug in GNU tar can be fixed with minimal effort. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
