Created attachment 191051 [details] ODF file with corrupted meta.xml The attached file couldn't be opened because the meta.xml is empty. This is an issue reported by our local users. However, 1. It can be opened by earlier version, 4.0.6.2 or 3.6.7.2. 2. We found that in sc/source/ui/docshell/docsh.cxx, when parsing the meta.xml, it is NOT a "must be successful" step. So we tried to make it pass and give a warning to users to save as a new file to restore the meta data. See also: https://gerrit.libreoffice.org/c/core/+/156574
See also: https://gerrit.libreoffice.org/c/core/+/159976 Since this is a broken package, the fix should set the RepairPackage media descriptor property to true, after a prompt. In package/source/zippackage/ZipPackage.cxx, there are checks related to the most fundamental things - e.g., for ODF packages, manifest is checked. But all the other XML streams can't be checked there; so the XML parser needs to do the job.
(In reply to Mike Kaganski from comment #1) > See also: https://gerrit.libreoffice.org/c/core/+/159976 > > Since this is a broken package, the fix should set the RepairPackage media > descriptor property to true, after a prompt. > > In package/source/zippackage/ZipPackage.cxx, there are checks related to the > most fundamental things - e.g., for ODF packages, manifest is checked. > > But all the other XML streams can't be checked there; so the XML parser > needs to do the job. Not sure if it is related to broken zip or not. In our case the ods file itself is zipped-okay, we could unzip it (so that we knew the meta.xml was wrong). No idea why meta.xml was emptied (since this file is from our user). Indeed it should be solved in more general way, not specific to Calc. However so far when we tried to search where to process/import meta.xml it was spread in different components like sc/, sd/, sw/, etc. Do you suggest us to add similar code to all those components, or is there another "upper" place to handle this at once?
(In reply to Dev from comment #2) > (In reply to Mike Kaganski from comment #1) > > See also: https://gerrit.libreoffice.org/c/core/+/159976 > > > > Since this is a broken package, the fix should set the RepairPackage media > > descriptor property to true, after a prompt. > > > > In package/source/zippackage/ZipPackage.cxx, there are checks related to the > > most fundamental things - e.g., for ODF packages, manifest is checked. > > > > But all the other XML streams can't be checked there; so the XML parser > > needs to do the job. > > Not sure if it is related to broken zip or not. In our case the ods file > itself is zipped-okay, we could unzip it (so that we knew the meta.xml was > wrong). No idea why meta.xml was emptied (since this file is from our user). > > Indeed it should be solved in more general way, not specific to Calc. > However so far when we tried to search where to process/import meta.xml it > was spread in different components like sc/, sd/, sw/, etc. Do you suggest > us to add similar code to all those components, or is there another "upper" > place to handle this at once? Actually we found that for Writer (sw) and Impress/Draw (sd) they've been taken care of. LibreOffice will give a warning, but still open odt/odp with corrupted meta.xml. Only Calc has this problem.
Lodev committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e91290190e4b2ef3cc07efb2bda42ea37b246354 tdf#158388 Allow user to open ODS file with corrupted meta.xml & settings.xml It will be available in 24.8.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.
Should this report be closed as fixed?