Closed prigaux closed 1 year ago
The reason client-zip version 2 always declares version 4.5 required to read is because of the streaming approach, it doesn't know in advance if the file will need Zip64 attributes (file size is known for sure only after copying all its data).
I'm sorry I haven't maintained version 1 very well (also, I haven't nagged contributors to make them develop non-Zip64 features in the nozip64
branch instead of master
) but your issue could be solved just by switching to client-zip@nozip64
, which specifies version 2.0 to read.
For client-zip 2.x to specify zip 2.0 entries, it would have to add some logic to check for usable metadata on each file, and then check for consistency. It's doable. Just not very useful since most use cases don't have that rather silly requirement you found in Microsoft Office.
Version 1.6.2 of client-zip is now up-to-date with all the recent bugfixes and features except empty folders and — of course — Zip64 (which Office clearly cannot read anyway). No more excuse not to use it to create your ODS or XLSX or any other MS Office document :)
Describe the bug
ODS generated with client-zip is invalid in Microsoft Office
To Reproduce Steps to reproduce the behavior:
Investigations Comparing various ODS that Microsoft Office accepts, Microsoft Office requires a ZIP "version needed to extract" 2.0 instead of 4.5
Possible workaround Lower the ZIP version number makes it work:
NB: I edited the issue because I thought I made it work with version 4.5 with different "META-INF/" entry but it seems it was a wrong test...