bug-tar
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]