search

AgentD / squashfs-tools-ng

A new set of tools and libraries for working with SquashFS images
Other
194 stars 30 forks source link

Premature end-of-file on some compressed tarballs #82

Closed AgentD closed 3 years ago

AgentD commented 3 years ago

When I try to pass the Linux 5.12. xz compressed release tarball (sha256sum 7d0df6f2bf2384d68d0bd8e1fe3e071d64364dcdc6002e7b5c87c92d48fac366) through tar2sqfs, it chokes after a short while, complaining about a premature end-of-file.

If I unpack the tarball, it works. If I used the gz compressed one (or unpack and then gzip it myself), it also works, so it is probably a problem with the xz stream wrapper. Interestingly, if I unpack and xz-repack it myself, it also works. Perhaps the kernel.org tarball uses stronger compression and the XZ decompression wrapper runs out of (pre-configured) work space memory?

Update: The xz decompressor returns an LZMA_STREAM_END half way through. Apparently the kernel.org tarballs are made up of several xz streams spliced together (from parallel compression?).

OT: Opening the issue on behalf of someone who couldn't be bothered to report this.

To anyone reading this: please, please, pretty please, if you find a bug, just tell me! I promise I won't be angry, annoyed, dismissive or whatever it is you fear. I actually have an interest in fixing those bugs. But if you never tell me about one, I won't know about it and it will persist.

There is also another issue in the above "review" post, that claims that tar2sqfs runs to completion without hitches but produces an image that is only a few K in size. Something that I cannot reproduce on my end. It would be really helpful if someone with the same problem could show me a tarball or otherwise tell me how to reproduce that.

AgentD commented 3 years ago

Presumably fixed by dd4e6ead142e58568aec89d76b0b2e867ee983f2