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

[Martin Koeppe]

On Mon, 13 Apr 2009, Kamil Dudka wrote:

> 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:
>
> Consider replacing it with this patch:
> https://bugzilla.redhat.com/attachment.cgi?id=334230

Thanks for the info. This isn't the problem for me, however.

And also it's no bug in tar, sorry for that assumption, I didn't look 
close enough. It's a portability thing:

On Interix fstat() returns st_mode==0 and st_nlink==0 for an unnamed 
pipe as created by pipe(2), and S_ISFIFO() reports false for those 
unnamed pipes.

So I now successfully patched tar-1.20 at sys_drain_input_pipe() in 
system.c.

I then tried to build tar-1.22. It builds ok and works without the 
above mentioned patch. So this problem has been resolved in between, 
and I don't attach my patch. However, one test fails in 1.22 while it 
is ok for 1.20:

 22: extracting selected members from pax   FAILED (extrac05.at:38)


Martin