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.
Received on Sun Dec 25 2016 - 01:19:02 CET