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
