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

[Mike Frysinger]

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.