sevenzip as a guide about sevenzip HOT 3 CLOSED

If it's LZMA, then the stream seems to need to have the size prepended to it, see the code here:

Every decoder gets passed the stream size and optionally some property bytes which it's free to interpret and use how it sees fit. So in this case I just write the size to a buffer (in little endian byte order) and then use an io.MultiReader to concatenate that and the actual stream together.

So what is probably happening is your LZMA reader is reading the first 8 bytes as the size and then complaining the first byte after that isn't zero.

Hope that helps.

from sevenzip.

@bodgit That was it! The properties bytes from the folder coder + the size of the uncompressed data as a little endian uint64 + the uncompressed data was the correct input. How did you ever figure that one out? I can't find it discussed anywhere. Thank you very much for sharing your expertise with me!

from sevenzip.

@bodgit That was it! The properties bytes from the folder coder + the size of the uncompressed data as a little endian uint64 + the uncompressed data was the correct input. How did you ever figure that one out? I can't find it discussed anywhere. Thank you very much for sharing your expertise with me!

Sorry, I didn't even spot that I was initializing the buffer with the property bytes as well! So yes, 5 property bytes and the 8 bytes for the size.

As for how I figured it out, the source of the LZMA library I'm using is pretty easy to read, in particular https://github.com/ulikunitz/xz/blob/master/lzma/header.go and https://github.com/ulikunitz/xz/blob/master/lzma/reader.go

The header length is 13 bytes and the code explains how it's packed so comparing that to the stream showed there was clearly some header bytes I needed to add in front.

Compare this to the LZMA2 implementation which uses the same library but is initialized differently; that doesn't care or need the size of the stream but you do have to use the property bytes correctly.

from sevenzip.