On Monday 13 April 2009 16:24:48 Martin Koeppe wrote: > 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.
while true not necessarily the fault of tar, that doesnt mean it cant be workedaround in it. -mike
signature.asc
Description: This is a digitally signed message part.
