On Mon, 27 Apr 2009 12:02:04 +0200 Uwe Kleine-König <u.kleine-koe...@pengutronix.de> wrote: > This is a regression from fixing http://bugs.debian.org/235820 plus (I > think) the upstream change described in http://bugs.debian.org/522858. > In tar-1.20 this doesn't show up. > > Reverting the diff for src/list.c makes this problem go away. It > doesn't fix #522858, though.
Fortunately, #522858 has since been fixed independently by a change in
dpkg, so we shouldn't have to worry about that at all. Meanwhile, the
proposal to revert the diff for src/list.c would undo the fix for
#235820 (which was to simply avoid printing a confusing warning when tar
was actually successful).
I think we can resolve the current bug without undoing the fix for
#235820 by reading the header, but remaining silent about any lone zero
block.
Please examine the patch below and let me know if you find it
acceptable. (The patch moves the #if 0 down to exclude only the printing
of the warning, without otherwise changing tar's behavior. The diff
doesn't make that as obvious as one might like.)
-Carl
commit 37efd16782afb35738fcd67c85f134fef2cc409f
Author: Carl Worth <cwo...@cworth.org>
Date: Wed Jul 29 16:10:01 2009 -0700
Don't close file stream before EOF, closes #525818
To fix bug #235820 src/list.c was modified to avoid printing
a confusing warning message about a lone zero block. However,
the change also caused the input stream to be closed before
reading EOF which could cause a SIGPIPE to be sent to the
writing process.
In this change, the previous fix is made more narrow to exclude
only the printing of the warning message, but without the side
effect that was causing the SIGPIPE.
diff --git a/src/list.c b/src/list.c
index c650172..126a3c1 100644
--- a/src/list.c
+++ b/src/list.c
@@ -136,7 +136,11 @@ read_and (void (*do_something) (void))
if (!ignore_zeros_option)
{
+ char buf[UINTMAX_STRSIZE_BOUND];
+ status = read_header (false);
+ if (status == HEADER_ZERO_BLOCK)
+ break;
/*
* According to POSIX tar specs, this is wrong, but on the web
* there are some tar specs that can trigger this, and some tar
@@ -144,11 +148,6 @@ read_and (void (*do_something) (void))
* let's not be pedantic about issuing the warning.
*/
#if 0
- char buf[UINTMAX_STRSIZE_BOUND];
-
- status = read_header (false);
- if (status == HEADER_ZERO_BLOCK)
- break;
WARN ((0, 0, _("A lone zero block at %s"),
STRINGIFY_BIGINT (current_block_ordinal (), buf)));
#endif
signature.asc
Description: This is a digitally signed message part
