7zip: Use compression settings from file also for file header #1532
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kientzle
reviewed
May 19, 2021
| @@ -755,14 +755,19 @@ _7z_close(struct archive_write *a) | |||
| */ | |||
| #if HAVE_LZMA_H | |||
| header_compression = _7Z_LZMA1; | |||
| if(zip->opt_compression == _7Z_LZMA2 || | |||
There was a problem hiding this comment.
Libarchive sources use tabs for indentation; please be consistent.
|
Nice! |
|
Do any tests need to be updated? |
|
All the tests still pass; I don't know if there should be any tests about such minute details. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The 7zip writer currently uses hard-coded values for the header compression (lzma1 if available and compression level 6).
This PR changes this behavior, so that the header is encoded in the same way as the rest of the archive.
I came across this when trying to read libarchive-created 7z file with the Apache Commons Compress Java Library. Because libarchive encoded the header differently then the rest of the file, the Java library failed with the error message "Compressed data is corrupt".
One could argue that this a bug with the Java library, but I think it's also a good thing for libarchive to use the same compression settings throughout the archive.
I have tried this version with different combinations of algorithm and compression level settings, and the files are all readable without problem with 7-zip.