[Top][All Lists]

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

Re: [Bug-tar] I: tar-1.23 SIGPIPE regression

From: Dmitry V. Levin
Subject: Re: [Bug-tar] I: tar-1.23 SIGPIPE regression
Date: Fri, 19 Mar 2010 23:34:36 +0300

On Fri, Mar 19, 2010 at 02:04:13PM -0600, Eric Blake wrote:
> On 03/19/2010 01:51 PM, Dmitry V. Levin wrote:
> > On Fri, Mar 19, 2010 at 09:15:28PM +0200, Sergey Poznyakoff wrote:
> >> Dmitry V. Levin ha escrit:
> >>
> >>> introduces a regression:
> >>>
> >>> $ touch empty && tar -cf empty.tar empty && tar -tf empty.tar | :
> >>> tar: write error
> >>
> >> This is intended behavior: instead of silently ignoring the error,
> >> tar reports it.
> > 
> > I understand that this change was intended, but I'm not sure that all
> > consequences of the change was taken into account.  Now an innocent code
> > like "tar -tf $file |grep -q $pattern" produces misleading error output,
> > and the only way to avoid it is to suppress tar's stderr completely. :(
> > I hope the change was not designed to produce such a negative side effect.
> It may be worth asking the question of the Austin group (the folks in
> charge of POSIX) whether or not a process that detects write failures
> because of EPIPE (when sigpipe is ignored) falls into the normal
> category of being required to diagnose the error and exit with non-zero
> status, or whether it should be special-cased and cause silent exits.
> Tar is not the first project where people have complained about the
> level of verbosity present due to EPIPE write errors, but without any
> further blessing from the POSIX folks specifically stating that EPIPE
> should be special-cased, we are only following the POSIX rules as we
> understand them.

I think the issue you are talking about is not the same as what has
happened with tar-1.23 due to the deliberate abovementioned change of
SIGPIPE handler from SIG_DFL to SIG_IGN.
tar now ignores SIGPIPE no matter what the caller process decides on this
matter.  I would understand if tar would treat EPIPE this way with the
inherited SIGPIPE signal state.  But I have no idea why tar should report
these EPIPE errors in case when the caller process deliberately sets
SIGPIPE handler to SIG_DFL.


Attachment: pgpiM5bdJ51uo.pgp
Description: PGP signature

reply via email to

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