Description: When opening such a file in LibreOffice 24 a general input/output error appears. After repacking the file (unzip and zip), everything is OK. LibreOffice 7.6 opens the file without a problem. System Windows 8/10/11. Steps to Reproduce: Open attached test_file.ods Actual Results: Inpuy/output error. Expected Results: No errors like with test_file_after_repacking.ods. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded
Created attachment 196981 [details] test_file.ods - generate input/output error, test_file_after_repacking.ods - opens without problems.
Confirm problem in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0a004f1a1528b8a85245de4672852b574bdc2cb2 CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded but not in Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL =>> regression
The file can be opened correctly with: Version: 24.2.5.2 (x86) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded So, this started after LO 24.2.5.2 (and before LO 24.2.6, according to the initial report).
On both ODF validator shows "The document is NOT conformant ODF 'Missing ODF version'! " among other issues. https://odfvalidator.org/
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed this: file test_file.ods => test_file.ods: Zip archive data, at least v2.0 to extract, compression method=store file test_file_after_repacking.od => test_file_after_repacking.ods: Zip archive data, at least v2.0 to extract, compression method=deflate Michael: since it concerns unzip management of the file, thought you might be interested in this one.
If I comment calls to ZipPackage::checkZipEntriesWithDD, the file opens well. So it seems related to 32cad89592ec04ab552399095c91dd76afb3002c package: ZipPackage: add additional check for entries STORED with ... data descriptor; only allow it for encrypted ODF entries, which requires reading the manifest first.
With this patch, it works: diff --git a/package/source/zippackage/ZipPackage.cxx b/package/source/zippackage/ZipPackage.cxx index 0ddc0906e02a..38a6f8847961 100644 --- a/package/source/zippackage/ZipPackage.cxx +++ b/package/source/zippackage/ZipPackage.cxx @@ -192,7 +192,7 @@ void ZipPackage::checkZipEntriesWithDD() { uno::Reference<XPropertySet> xStream; getByHierarchicalName(rEntry.sPath) >>= xStream; - if (!xStream->getPropertyValue("WasEncrypted").get<bool>()) + if (xStream->getPropertySetInfo() && xStream->getPropertySetInfo()->hasPropertyByName(u"WasEncrypted"_ustr) && !xStream->getPropertyValue("WasEncrypted").get<bool>()) { SAL_INFO("package", "entry STORED with data descriptor but not encrypted: \"" << rEntry.sPath << "\""); throw ZipIOException( but is it the right way to fix this?
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3efad499bf4f7623610a54f9f14622de4954352f tdf#163364 package: ask to recover for this invalid ODF package 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.
oh really? a data descriptor on a folder zip entry? since it's pointless i didn't expect anybody to do that... the error handling is bad, the user should be asked to recover the file. the first entry in the zip should be "mimetype" so it's invalid anyway. fixed (error handling improved) on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/5c39f9db930fa2ca91792bf109f432741b4c16f4 tdf#163364 package: ask to recover for this invalid ODF package 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/92939c34eb22c556fce1f19066854c035297fcb9 tdf#163364 package: ask to recover for this invalid ODF package 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 the initial file can be opened after LO repairs it. Thank you Michael for the quick fix!