Fixed extractions after first ZIP64 entry is read from stream #852
Conversation
This file contains hidden or 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
The last commit made in this branch messed up some ZIP reading and caused a bunch of tests to fail. These changes branch off ZIP64 logic into its own block so that data is read correctly for 64 and non-64 entries.
Reorders this null reference check to avoid throwing a null reference exception.
Contributor
Author
|
Not sure why tests are failing here... is |
Owner
|
format is using csharpier to enforce a code style. The dotnet tool is available locally and |
Owner
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
When a ZIP64 entry is extracted from an archive, the header for the next entry is read out of order. This commit reads the header again, then resets the position of the RewindableStream back to the beginning of the entry, just after the 4 byte header signature. This ensures the correct header signature data and reader (in the correct position) are fed to ReadHeader. Previously this would have read the data at an incorrect offset and would not yield a viable ZipHeader.
I haven't done extensive testing with this nor did I write any automated tests.