Bug: Unable to Find ZIP Signature in Large ZIP Files #69870
+3
−3
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.
I am encountering an issue when attempting to read large ZIP files using the Go archive/zip package. The current implementation of the readDirectoryEnd function only searches for the ZIP directory end signature (0x050605) in the last 1KB and 65KB of the file. This approach does not account for cases where the ZIP file might have a larger directory section, especially in ZIP64 files.
Steps to Reproduce:
Create a large ZIP file (greater than 65KB) that contains several entries.
Attempt to read the ZIP file using the archive/zip package.
Observe that the signature for the ZIP directory end cannot be found, resulting in an error indicating that it is not a valid ZIP file.
Expected Behavior:
The readDirectoryEnd function should effectively search for the ZIP directory end signature across a larger range of the file, especially for ZIP64 files, which can have directory entries that exceed the current search limits.
Proposed Solution:
I suggest modifying the readDirectoryEnd function to increase the search range for the directory end signature. For example, consider searching within the last 5M of the file or implementing a more comprehensive search strategy that can handle ZIP64 files more effectively.
Thank you for your attention to this matter. I hope this issue can be addressed in a future release.