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

[Martin Koeppe]

On Sun, 12 Apr 2009, Martin Koeppe wrote:

> On Wed, 18 Feb 2009, Sergey Poznyakoff wrote:
>
> > Martin Koeppe <address@hidden> ha escrit:
>
> > > I'm using GNU tar on Interix. See http://www.debian-interix.net/
> > > for more details.
> > >
> > > I encountered some .tar.gz files which I cannot extract correctly.
> > > Most others work well. One of those failing files is:
> > > http://ftp.de.debian.org/debian/pool/main/s/smstools/smstools_3.1.orig.tar.gz
> > >
> > > I get:
> > >
> > >   $ tar --version
> > >   tar (GNU tar) 1.20
> > >   Copyright (C) 2008 Free Software Foundation, Inc.
> > >   License GPLv3+: GNU GPL version 3 or later
> > >   <http://gnu.org/licenses/gpl.html>
> > >   This is free software: you are free to change and redistribute it.
> > >   There is NO WARRANTY, to the extent permitted by law.
> > >
> > >   Written by John Gilmore and Jay Fenlason.
> > >
> > >   $ tar xzf smstools_3.1.orig.tar.gz
> > >   tar: Child died with signal 13
> > >   tar: Error exit delayed from previous errors
> > >
> > > The archive gets extracted anyway, but tar fails. These ones both work, 
> > > however:
> > >
> > >   $ gzip -d -c smstools_3.1.orig.tar.gz | tar xf -
> > >   $ cat smstools_3.1.orig.tar.gz | tar xzf -
> >
> > I cannot reproduce it. What are your tar defaults (see tail of `tar
> > --help' output)?
>
> 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.

I had a closer look at the tar sources and now I think I found the 
problem, which appears to be a bug in tar:

In tar-1.20 there is a function sys_drain_input_pipe() which actually 
works (and eats the trailing zeros from gzip) if 
S_ISFIFO(archive_stat.st_mode) is true. On Interix, 
archive_stat.st_mode == 0, i.e. no FIFO, so sys_drain_input_pipe() 
doesn't do anything.

In tar-1.22 there is no sys_drain_input_pipe() any more, but the bug 
which yields to st_mode == 0 is still there:

In buffer.c:567 open_compressed_archive() is called, later at line 599 
sys_get_archive_stat() is called. Unfortunately, within 
open_compressed_archive() on line 308 the FD is closed so that fstat() 
is then called on a closed FD, which on Interix yields to st_mode == 0.


Martin