[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] closed stderr can make tar corrupt its output archive
From: |
Jim Meyering |
Subject: |
Re: [Bug-tar] closed stderr can make tar corrupt its output archive |
Date: |
Sun, 28 Aug 2005 11:16:07 +0200 |
Joerg Schilling <address@hidden> wrote:
> Jim Meyering <address@hidden> wrote:
>
>> > 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.
>
> If your head program accepts -c39, I would call this a bug.
It's a long-standing feature of GNU head:
head --bytes=N (-c N)
You're the first in 13 years to call it a bug.
...
> But the problem not is that a program incorrectly asumes that open()
> would never return 2.
>
> The "problem" is that the program correctly asumes that stderr is an
> open fd at program startup. There was a related discussion some time
> before on the POSIX mailing list.
POSIX provides no guarantee that any file descriptor will be open
at startup. But in programs that are run set-ID, reopening on e.g.,
/dev/null is permitted. If the standard ever does allow such behavior
for non-set-ID programs, it will have to adjust the meaning of the
shell's N>&- syntax.
> With star in (default mode with FIFO) you get even other problems.
> The libschily error output rutines check the write(2) return code
> and abort star because of the write problem when fd#2 is not open.
I'd rather not make any GNU coreutils program abort just because someone
(probably accidentally or unknowingly) invoked it with closed stdin,
stdout, or stderr. Even programs that *may* use a stream like stderr can
usually work just fine if that stream is initially closed. Would you like
touch or cp to abort if invoked like this
touch foo 2>&-
I certainly wouldn't.
> If I recall the POSIX discussion correctly, if POSIX would explicitly
> allow this, the correct fix would be to enhance the startup code before
> main() is called to make sure that things are as expected.....
Finding an acceptable definition of `as expected' and changing the
standard to *allow* that new behavior will take time. Maybe a very
long time. If this happens, it will be years before the majority
of systems provide such protection.
Re: [Bug-tar] closed stderr can make tar corrupt its output archive, Sergey Poznyakoff, 2005/08/28