Fix corruption of large files when zip64 is used #113
Merged
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
Previously the code did not account for the fact that the initial stub local header (with uncompressed and compressed sizes set to 0) could not serve for correct estimation of the final local header size due to the fact that the local header size was determined by the uncompressed and compressed sizes of the corresponding data, which are only known after streaming of the data. These sizes dictated whether or not a zip64 extra field entry should be included in the header or not. Thus, before this fix there would be cases of corruption where the final (longer) local header written by seeking back to the beginning of the initial stub local header after the data had been streamed would overwrite the beginning of the data. This is fixed by * always writing a zip64 entry in local headers, which does not violate the spec and will be safely ignored in the case of smaller entries, and * respecting the spec more precisely where it says that whenever there is a zip64 extra field entry in a local header both uncompressed and compressed sizes must always be written. This is deemed safe because the only source of size variation for local headers is the uncompressed and compressed sizes of the corresponding data.
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.
Close #111.
Previously the code did not account for the fact that the initial stub local header (with uncompressed and compressed sizes set to 0) could not serve for correct estimation of the final local header size due to the fact that the local header size was determined by the uncompressed and compressed sizes of the corresponding data, which are only known after streaming of the data. These sizes dictated whether or not a zip64 extra field entry should be included in the header or not. Thus, before this fix there would be cases of corruption where the final (longer) local header written by seeking back to the beginning of the initial stub local header after the data had been streamed would overwrite the beginning of the data.
This is fixed by
This is deemed safe because the only source of size variation for local headers is the uncompressed and compressed sizes of the corresponding data.