Willy Gfn wrote:
> Michael Forney wrote:
> > On 12/24/16, Cág <caoc_AT_riseup.net> wrote:
> > > Markus Wichmann wrote:
> > >
> > >> Well, that looks like it might be problematic, doesn't it? Especially
> > >> when you find out, that the size of h->name there is 100 bytes. path
> > >> contains, of course, the entire file path relative to the starting
> > >> directory. In short, you will get this error message whenever trying to
> > >> package files with a total relative path length of more than 100
> > >> characters.
> > >
> > > Indeed, I've just tried to compress an extracted Linux kernel
> > > (that doesn't have .git folder), it went without errors. Thanks for
> > > pointing out.
> > >
> > > But when I tried to extract it, it still said "malformed tar archive".
> > > Here's the part with it: http://git.suckless.org/sbase/tree/tar.c#n404
> >
> > Fixing up tar bugs in sbase has been on my TODO list for a while. It's
> > the one tool I'm not using from sbase.
> >
> > One thing that might be related is that in various places, it uses
> > eread(..., BLKSIZE), expecting that exactly BLKSIZE bytes are written
> > (skipblk, xt, unarchive). But, if you are extracting from a pipe
> > hooked up to a decompression program, it may be less than that. When
> > this happens, it calls chktar on a random piece of data from the
> > archive, which fails the checksum check.
> >
> > I think we should add a readall function to libutil, similar to the
> > writeall function I sent in a patch set a few weeks ago.
> >
> > I think I have a pending patch to make the "malformed tar archive"
> > errors more specific, but it's on a different computer and I am
> > visiting family for the holidays. If you want to try and debug the
> > error, I'd start with trying to figure out why it thinks it is
> > malformed. I suspect it is due to a bad checksum.
>
> Bumping this thread because I've been testing it a bit. I attached a
> patch to make the error more descriptive, and this patch shows that the
> most common error (to me) is a bad magic and that is certainly because the
> magic is checked before the checksum. Sometimes the magic check pass,
> but it then fails on the checksum.
>
> This is indeed due to a short read from a pipe, because if you try to
> print the said "bad magic", you end up with a chunk of the previously
> extracted file. I will look into this "readall" function to submit
> a patch.
>
> Something worth noticing is that I only encountered this bug with bzip2
> when it's compiled against musl. I couldn't reproduce it with glibc.
I managed to fix this bug by changing the eread() function. I'll send
an email with my patches in a new thread.
Received on Fri Feb 03 2017 - 15:21:47 CET