Re: [Help-tar] Does GNU tar close its input pipe before seeing EOF on it?

[Ersek, Laszlo]

On Mon, 1 Mar 2010, Sergey Poznyakoff wrote:

> Ersek, Laszlo <address@hidden> ha escrit:
>
> > Does GNU tar (and if so, under what circumstances) close its input
> > pipe before seeing EOF on it?
>
> Yes, it does. The input stream is closed if tar determines that
> there is nothing more to be read from there (e.g. it has received
> the two null blocks that end the archive or has extracted all
> requested files).

Thank you.

> From the tar-1.22.91 alpha release (and I apologize if it's obsolete or 
irrelevant for this discussion), "src/system.c", sys_wait_for_child():

   173        if (WIFSIGNALED (wait_status))
   174          {
   175            int sig = WTERMSIG (wait_status);
   176            if (!(!eof && sig == SIGPIPE))
   177              FATAL_ERROR ((0, 0, _("Child died with signal %d"), sig));
   178          }
   179        else if (WEXITSTATUS (wait_status) != 0)
   180          FATAL_ERROR ((0, 0, _("Child returned status %d"),
   181                        WEXITSTATUS (wait_status)));

It seems that tar considers it okay when its child filter dies with 
SIGPIPE *if* tar has not yet seen an EOF on the pipe. I guess the 
motivation is to accept a SIGPIPE in response to tar closing the pipe 
early.

Consider a filter encountering a genuine error. The filter intends to 
print an error message to stderr, then exit with a non-zero exit status. 
Suppose the filter is killed with SIGPIPE when it tries to print the error 
message, because its STDERR_FILENO refers to a pipe (or socket) that is 
broken. What will tar do?

Do we trust tar to notice the problem by detecting the incomplete tar 
stream and/or the bad checksum? What if the filter produces a stream 
carrying multiple concatenated tar files (suppose tar was started with the 
appropriate options), and the problem occurs in the filter at the boundary 
between the two tar files?

Another case is when the filter does not encounter an error, but simply 
tries to produce a great amount of diagnostic output (like some verbose 
progress report or debug trace), and its stderr pipe is broken.

In short, can tar be sufficiently certain that any SIGPIPE returned for 
the child, before tar meets EOF on the pipe, is due to tar closing the 
pipe?

Thank you very much,
lacos