Mult-tab preadsheet autosave recovers as a single blank tab, appears to be some internal file error

English
#1

Tested on the following variants of LO and Excel.
LO 7.5.4.2 on Linux Mint 21 (Vanessa) (and a different machine running Ubuntu 22)
LO 7.1.3.2 x64 and LO 7.6.0.0b1 and Office 2021 on Win 10
LO 6.4.7.2 and Excel 2007 x64 on Win 7

Problem: cinnamon hangs pretty regularly on Linux mint, sometimes killing the process permits recovery, but not always, this was one of those times. I ssh’d in and rebooted cleanly, though obviously couldn’t tell the GUI apps to save/exit.

Restarting LO after reboot I got the usual unsaved recovery and happily “recovered” my unsaved docs, but they came up blank. No error, but no data in the spreadsheets or tabs.

I tried disabling hardware acceleration, but that didn’t fix it, file appears to be corrupt, alas.

I tried two versions of excel on Windows - and both Excels report an error and offers to recover as much data as possible, which is, alas, zero.

I unzipped the .ods file and poked around the XML files, but I couldn’t find anything obvious and the data in content.xml looks normal to me. The XML structure is minified and somewhat challenging to visually parse as raw text. Pretty XML in VSCodium is trying to format it, but this looks like a very extended operation.

I can see that the data is there, Brave/Chrome parses it nicely, everything seems properly terminated. I tried creating a blank ods container and dropping the content file into it, but to no avail, that also opens blank.

I even have a previous version from my NextCloud sync from a few hours earlier that has less data in it (66k), but that one also opens to a single blank tab, as does an even earlier version (22k). :frowning:

So, bummer. If anyone has some time and expertise to poke at it, the file is at:

https://brt.llc/insecure/planes_batteries_solar.ods

I’d very much appreciate any hints or advice.

#2

Something seriously messed around with the element and attribute names in content.xml and replaced several with others. Luckily in some “logical” manner. That’s not something LibreOffice would do unless the executable binary / some library is corrupted at the mapping table of IDs to XML names, a mismatch between library versions, or disk or RAM is rotten or some such…

I repaired content.xml by doing the following replacements:

office:spreadMethod -> office:spreadsheet
table:table-background -> table:table
table:name-and-extension -> table:name
table:table-column-group -> table:table-column
table:table-row-group -> table:table-row
table:table-centering -> table:table-cell
text:package-name -> text:p

See the resulting document attached.
There may be more quirks lurking, but these were the obvious. There are also quite a few table:number-columns-spanned="..." that don’t make much sense to me and even cover cells with content, inspect the document and you may want to unmerge all cells on all sheets.

If I were you I’d thoroughly check the Mint installation and machine.

92665ask-planes_batteries_solar-repaired.ods (77.3 KB)

3 Likes
#3

Oh thank you! That’s awesome and at least the data is visible again in tabular form. The structure is badly broken but I have a path to repair, either manual or search and replace thanks to your excellent insight.

I’m not seeing any indications of errors other than that cinnamon often crashes overnight, and while there’s one report of something similar being caused by bad RAM, I’m not seeing any such issues. I’ll do a BIOS ram check and see if anything comes up.

It is possible something got scrambled brains though, the mechanism could be that the LO content got pushed to VM (only 32GB RAM), then the cinnamon problem hits which locks up a lot of IO. How that might have scrambled name spaces, I don’t know. It looks like some lookup failed and the namespace was shifted, like 1 down or something. Google isn’t turning up anything with these attribute names, alas.

#4

I tested RAM (no problems) and disk (limited test, but no problems). I don’t see how a random variation could have caused such chaos, but possibly a shift in an internal index to naming space could have. It is entirely possible there was an update of some relevant library or schema while the file was open (I don’t generally reboot often).

If anyone has a reference namespace schema (I searched and couldn’t find one) it may be a simple transposition that can be reversed, otherwise I’ll generate a reference document and look for name space correlations. It’d be lovely to recover the file, but thanks to @erAck’s excellent help, it is gone from disaster to annoyance. (thanks again!)

#5

If that (updating while the application was running) was the case then it could had certainly been the cause for this, as still in memory IDs may had been pointing to then different mapping entries (or vice versa).

The Relax-NG schema for ODF v1.3 plus LibreOffice extensions is at schema/odf1.3/OpenDocument-v1.3-schema.rng - core - Gitiles and schema/libreoffice/OpenDocument-v1.3+libreoffice-schema.rng - core - Gitiles

There’s also ODF Validator.

1 Like
#6

you rock! Thank you very much. I’ll keep in mind to flush and reload the datas around updating in the future.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.