On Sun, 12 Apr 2009, Martin Koeppe wrote:
On Wed, 18 Feb 2009, Sergey Poznyakoff wrote:
Martin Koeppe <[email protected]> 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
