The file 'Anyname.odt' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file

[AniruddhaMohod]

I am using Ubuntu 22.04 and LibreOffice 24.8.4.2 We used to download an .odt file everyday from our software. When we try to open the file we are getting following error.

The file ‘Anyname.odt’ 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?

We are getting this error after recent updates of LibreOffice. Previously we do not used to get such error. Even if I open files of past several files recent version of LibreOffice is giving this error. LibreOffice says it will repair the file. LibreOffice repairs the file and I have to resave the file and it works OK. But I have to resave the repaired file every day.

I am attaching a sample file for your kind perusal.
English Roznama.odt (10.7 KB)

[mikekaganski]

The file that you attached was saved using Apache OpenOffice 4.1.3. What happens there in your software (“We used to download an .odt file everyday from our software”)? When I re-save the file locally using LibreOffice, and then re-open it, it shows no error. I think, that what you see is the result of changes in 24.8 to harden the security of handling ODF packages. Specifically, after commit efae4fc42d5fe3c0a69757226f38efc10d101194; you may have found a bug (or maybe not - needs investigation).

[mikekaganski]

BTW: opening the bugdoc in Word 2016 also shows a warning:

And the package really looks strange. Not only the AOO 4.1.3 looks odd (even if you use AOO, then why use an outdated version, when even they have released several bugfix versions with security fixes in the meantime - their current version is 4.1.15); but the ZIP itself looks changed outside of the generating software (it has elements packed in an order different than AOO packs them; the file dates there are set to 2018-12-28; for content.xml, unlike all others, the ZIP version for extraction is set to 1.0 - while the standard requires 2.0).

I am inclined to blame the server software, which likely breaks the correct ZIP structure.