I have tried all the usual options, starting in Safe Mode, disabling hardware acceleration and anti-aliasing. My file.ods just will not open. What other options should I try? If the file is truly hoofed, is there a way to read the contents with another application so that at least I can recover part of the file?
The Calc file (*.ods) is a zip archive in structure. As a first step, rename the extension to .zip and try to check the integrity of the archive with any appropriate program.
Here is the result of my integrity test, everything looks o.k.
[~]$ unzip -t 2023ja.zip
Archive: 2023ja.zip
testing: mimetype OK
testing: Configurations2/accelerator/ OK
testing: Configurations2/images/Bitmaps/ OK
testing: Configurations2/toolbar/ OK
testing: Configurations2/statusbar/ OK
testing: Configurations2/progressbar/ OK
testing: Configurations2/toolpanel/ OK
testing: Configurations2/menubar/ OK
testing: Configurations2/popupmenu/ OK
testing: Configurations2/floater/ OK
testing: manifest.rdf OK
testing: meta.xml OK
testing: styles.xml OK
testing: content.xml OK
testing: Pictures/10000000000003B30000014F5F0C95C3C5923053.png OK
testing: settings.xml OK
testing: Thumbnails/thumbnail.png OK
testing: META-INF/manifest.xml OK
No errors detected in compressed data of 2023ja.zip.
Here is the contents of the unzipped file…
[2023ja]$ ls
Configurations2 manifest.rdf meta.xml Pictures styles.xml
content.xml META-INF mimetype settings.xml Thumbnails
There are chances for a cure.
If your file does not contain confidential information, then upload it and one of the experts will probably fix it (if possible).
Otherwise, contact the expert by mail (or private message).
Unfortunately, the file contains personal financial information. I guess I will have to build from last year’s file…and revisit my poor backup strategy. Thanks for responding.
There is an error message?
You didn’t mention your OS. I saw some questions recently, where files actually opened to very tiny windows on Linux - easily missed and no error message.
.
Depending on your OS try to find out, if there are open windows and if LibreOffice is running or not.
That is an interesting question…Fedora 37, so Linux. At the bottom of LO, there is a bar that advances showing that LO is trying to load the file. When I unzipped the .ods file, I took a look at all the xml files. Only content.xml would not open. I even used vi to open it and it crashes vi.
Try if
xmllint --format content.xml >testoutput.xml
gives any insights, either already when running the command or when inspecting the output file. If vi (which is probably aliased to vim) for some reason (I’d guess it’s because the file is huge and you have syntax highlighting on) doesn’t handle it (I’d say it didn’t crash but just takes ages to complete or loops infinitely), then use less to view the file.
You can also use the https://odfvalidator.org/ service to formally validate the structure of the document file, for ODF Version choose OASIS ODF 1.3 (extended conforming) and Logging only warnings and errors.
I ran the xmllint command and eventually the line “killed” appeared at the command prompt. The testoutput.xml file was generated but it had no content. When I ran the command less content.xml, a few concatenated lines of code/info appeared but I could not advance the screen using the space bar. I had to eventually use ctrl-Z to kill the process. I was not aware of the odfvalidator.org site. I tried to validate the content.xml file and received this message ’ 413 Request Entity Too Large’. So, your guess that the file is ‘huge’ is correct. I rebuilt my file from scratch so this aventure is just another nudge to have better backups.
Sounds more like content.xml is not just huge but contains incomplete invalid XML or even arbitrary binary garbage, but correctly zipped. Odd.