Re: [Bug-tar] SIGPIPE problem and regression for tar 1.21 on Interix

[Kamil Dudka]

On Sunday 12 of April 2009 12:26:29 Martin Koeppe wrote:
> I have now narrowed down this issue. The best example now is the
> Debian source for GNU tar. While I could successfully extract
>    http://ftp.de.debian.org/debian/pool/main/t/tar/tar_1.20.orig.tar.gz
> I cannot extract
>    http://ftp.de.debian.org/debian/pool/main/t/tar/tar_1.22.orig.tar.gz
> anymore. When gunzipping this tar_1.22.orig.tar.gz file, then one can
> see that more than 10k (20*512) bytes of zeros (actually there are 21
> 512-byte blocks) are at the end of the uncompressed tar file.
>
> Looking at the above mentioned smstools_3.1.orig.tar.gz also shows 21
> 512-byte blocks of zeros at the end. I verified this for several other
> failing archives, too.
>
> As this works on Linux, it's surely a portability issue. strace on
> Linux shows that the trailing zeros are read, while truss on Interix
> shows that they aren't. I would like to ask what part of tar might be
> responsible for this behaviour.

IMHO it's not bug in the upstream version of tar but rather in the debian 
patchset. This is the culprit:

--- tar-1.22.orig/src/list.c
+++ tar-1.22/src/list.c
@@ -136,6 +136,14 @@

      if (!ignore_zeros_option)
        {
+
+         /*
+          * According to POSIX tar specs, this is wrong, but on the web
+          * there are some tar specs that can trigger this, and some tar
+          * implementations create tars according to that spec.  For now,
+          * let's not be pedantic about issuing the warning.
+          */
+#if 0
          char buf[UINTMAX_STRSIZE_BOUND];

          status = read_header (false);
@@ -143,6 +151,7 @@
        break;
          WARN ((0, 0, _("A lone zero block at %s"),
             STRINGIFY_BIGINT (current_block_ordinal (), buf)));
+#endif
          break;
        }
      status = prev_status;

Consider replacing it with this patch:
https://bugzilla.redhat.com/attachment.cgi?id=334230


Kamil