Willy Gfn wrote: > Michael Forney wrote: > > On 12/24/16, Cág <c...@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.
