[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ersek, Laszlo
Subject: Re: [Help-tar] Does GNU tar close its input pipe before seeing EOF on it?
Date: Tue, 2 Mar 2010 13:49:36 +0100 (CET)

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,

reply via email to

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