Description: If I make an ODS spreadsheet using the Python package stream_write_ods https://github.com/uktrade/stream-write-ods, but using its (new) use_zip_64=True flag, then LibreOffice reports the file as corrupt. This is in spite of the file validating as valid ODF at https://odfvalidator.org/, and validating as a valid ZIP file using `unzip -t`. Passing use_zip_64=False into stream_write_ods results in a file that opens in LibreOffice without error. Full disclosure: I am a maintainer of stream_write_ods, as well as its underlying zip library. Of course, there _could_ be a problem at the ZIP level (ZIPs are not easy!), but so far I've not found it Steps to Reproduce: 1. Install Python (e.g. Python 3.11) 2. Install the latest version of stream-write-ods pip install stream-write-ods==0.0.25 3. Create a Zip64 ODS file using the following Python script: from stream_write_ods import stream_write_ods ods_chunks = stream_write_ods(( ( 'Sheet 1 name', ('col_1_name', 'col_2_name'), ( ('Value A', 'Value B'), ('Value C', 'Value D'), ) ), ), use_zip_64=True) with open('test.ods', 'wb') as f: for chunk in ods_chunks: f.write(chunk) 4. Attempt to open the file in LibreOffice Actual Results: The following message appears: ---------------- The file 'test.ods' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file. The corruption could be the result of document manipulation or of structural document damage due to data transmission. We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. Should LibreOffice repair the file? Expected Results: The files opens as a spreadsheet without error Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.2.1 (AARCH64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 196950 [details] Python script to create a Zip64 test.ods file
Created attachment 196958 [details] ODS file in Zip64 format An ODS file using Zip64 created by the attached Python script
On pc Debian x86-64 with master sources updated today, I could reproduce this. Renaming test.ods into test.zip then using: zip -F test.zip --out test2.zip work and finally renaming test2.zip into test2.ods, it works. Michael: thought you might be interested in this one considering the work you did on Zip management.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/279f42fa8b19d4fe81c3bba4c7af21aa8ab135b9 tdf#163341 package: fix reading Zip64 produced by stream-write-ods It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
the ODF validator is using Apache Commons Compress which abstracts away lots of interesting things that can't be checked... due to the lack of error reporting infrastructure in the sfx2 module, the problems that are detected by LO cannot be displayed to the user, you need a debug build and run with SAL_LOG="+INFO.package+WARN" to see them... i don't see anything obviously wrong with the attachment, replacing the "disk numbers" with 0xFFFF is funny but allowed, and the bad handling of 64-bit offset later on is an indication that there aren't enough Zip64 unit tests... fixed on master
(In reply to Michael Stahl (allotropia) from comment #5) > replacing the > "disk numbers" with 0xFFFF is funny but allowed btw, please don't send me your ODF file split across 64k+1 floppy disks, the multi-disk zips are out of scope for LO :)
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/b9160c7f95c54028a6948c4f3aff113bd29df686 tdf#163341 package: fix reading Zip64 produced by stream-write-ods It will be available in 24.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/9e95415b24c4127873b1b121402cc5356d6116b6 tdf#163341 package: fix reading Zip64 produced by stream-write-ods It will be available in 24.2.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On pc Debian x86-64 with master sources updated today, I confirm sheet can be opened. Thank you Michael!
Ah thank you for this! One thing on the change, should it be using the 0xFFFF value of disk number as an indicator that it should look at the corresponding Zip64 value, and then only erroring out if _that_ value isn’t zero?