mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #228] Turn on ZIP64 support #184
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#184
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @evanmiller on GitHub (May 15, 2019).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/228
Originally assigned to: @jmcnamara on GitHub.
I get an error when creating an especially large XLSX file (see #227). The underlying error is
ZIP_BADZIPFILE, triggered athttps://github.com/jmcnamara/libxlsxwriter/blob/master/third_party/minizip/zip.c#L1731
I believe this can be fixed by changing the last argument to
zipOpenNewFileInZip4_64be1instead of0here:https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L1063-L1069
I.e. that turns on Zip64 support which permits 4GB+ uncompressed file sizes to be written.
@jmcnamara commented on GitHub (May 15, 2019):
Agreed. That could/should be added. It is supported in the Python version of the library: https://xlsxwriter.readthedocs.io/workbook.html#workbook-use-zip64
@jmcnamara commented on GitHub (Jun 7, 2019):
I've added this to master.
From the docs:
And from a sample file generated with the ZIP64 extensions:
@evanmiller commented on GitHub (Jun 8, 2019):
Would
use_zip64make more sense as a field inlxw_workbook_options? That would seem to provide a more consistent API than a one-off function like this.@jmcnamara commented on GitHub (Jun 8, 2019):
That was my first thought but the Python version uses a function/method (use_zip64()) so I went with that.
The
lxw_workbook_optionsare mainly for options that need to be defined at construction time or are very common. The zip64 option isn't in either of those categories and doesn't seem to be very commonly required. You are only the second person to request or mention it across the Perl/Python/C versions. So I'll leave it as a function for now, but I'll think about it up until the release.@evanmiller commented on GitHub (Jun 8, 2019):
Well, I have been using libxlsxwriter in shipping code for a number of years, and Zip64 wasn't something I knew I needed until recently. It took some fairly deep debugging to figure out that its absence was triggering write failures. If it had been an advertised option sooner, I certainly would have enabled it. So I suspect that many clients of libxlsxwriter will choose to enable Zip64 once they are made aware of it.
One advantage of using an option instead of a function is that in the future, you will be able to make Zip64 the default (opt-out) without changing the API. The new API is opt-in only.
@jmcnamara commented on GitHub (Jun 8, 2019):
Okay. I'm persuaded. I'll enable it in the
lxw_workbook_options.@jmcnamara commented on GitHub (Jun 8, 2019):
I've refactored the
use_zip64option into the constructor. It can now be called as follows:When you get a chance try it out and see what you think. The docs have been updates as well.
@jmcnamara commented on GitHub (Jun 8, 2019):
After I fix the failing test cases on Linux.
@jmcnamara commented on GitHub (Jun 8, 2019):
Okay. Master is fixed again.
@evanmiller commented on GitHub (Jun 8, 2019):
The new code is working as expected. Thanks.