Re: [Bug-tar] closed stderr can make tar corrupt its output archive

[Jim Meyering]

Joerg Schilling <address@hidden> wrote:

> Jim Meyering <address@hidden> 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.