-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support legacy LZMA format with unpacked_size
32bit long
#13
Comments
Do you have a reference to the code or documentation, and example files to test this? Otherwise it will be hard to add support for this use case. Feel free to send a pull request as well! |
Yes, see how it is done https://github.com/XVilka/ocaml-lzma_7z/blob/master/lzma.ml#L387 One of the cases it was used - very old 7Zip SDK, which was used in the modified CramFS version that used LZMA: Note how it is used 32bit ints for outsize: |
Would #17 (or a variant of it) work for this use case? |
Yes, ability to form the header manually is good enough, thanks! |
The implementation in #17 only supports a 64-bit or 0-bit field for the unpacked size though. So I assume it wouldn't work for a 32-bit unpacked size out-of-the-box. |
@gendx someone also needs this feature it seems, not only me: https://users.rust-lang.org/t/extract-lzma-file/24793/5 |
Thanks for the pointer. I don't have a lot of time for implementing it at the moment, nor files from the old SDK to test with. But feel free to send a pull request, I'll be happy to take a look! |
If the |
Will this do ?
} |
Tests will look as follows
} ` |
Old versions of lzma SDKs (e.g. from 7zip) were using 32bit long field for the unpacked size in the header. Would be awesome to have support for these too.
The LZMA SDK 4.05 (from 2004 year) for example handles it this way.
The text was updated successfully, but these errors were encountered: