fix: Malformed ZIP64 file output (#715)#717
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the handling of Zip64 extended information in central directory headers. It introduces a mechanism to explicitly mark files as 'large', ensuring that the necessary Zip64 fields are always written for them, regardless of their specific size values. This change improves the robustness and correctness of ZIP archive generation, particularly for files that might be logically large but have zero or small reported sizes under certain conditions. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
The PR correctly adds the missing is_large_file parameter to Zip64ExtendedInformation::central_header() and updates the call site. The central_header function was already checking is_large_file in its logic (lines 80, 86) but the parameter wasn't being passed from the caller, which would have caused the condition to always be false. This fix ensures that files explicitly marked with large_file: true will consistently use ZIP64 extra fields in both local and central directory headers, even when file sizes are below the 4GiB threshold.
Note: The PR title should follow Conventional Commits format (e.g., "fix: add missing is_large_file parameter to central_header").
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
There was a problem hiding this comment.
Code Review
The pull request introduces an is_large_file boolean parameter to the Zip64ExtendedInformation::central_header function. This parameter is now passed from the write_central_directory_header function and is used to explicitly include uncompressed and compressed sizes in the ZIP64 extended information block if a file is designated as large, even if its size does not exceed the ZIP64_BYTES_THR threshold.
|
@Pr0methean I think we should merge this Or wait for a test Or add the test later |
|
I think https://github.com/zip-rs/zip2/pull/265/changes is not correct and |
Pr0methean
left a comment
There was a problem hiding this comment.
Just a couple of nitpicks.
dimissing the review (fixed) to merge queue
fix: #715
Also fix the zip64 central directory creation and add a test