Cannot open file saved with LO 4.2.x / How to recover?

English
, , ,
#1

I have a file saved with LibreOffice 4.2.something in mid 2014 (which was actual release for that time?).
Trying to open it with both LO 4.3 and 4.4 causes error display:

Read-Error. Format error discovered in the file in sub-document content.xml at 2,185351(row,col).

If I test them as ZIPs, they’re fine.
I have two similar documents, created and saved same day, using same LO version, both have same sign of corruption (or is it?).

Here they are:

I’m not that worry about contents of these docs, because, if needed, I can find LO version which will open them. What I worry about is, is there some universal recovery procedure to “normalize” a semi-corrupted doc (like this) and avoid reinstalling multiple LO versions to find one working?
Maybe it will even work for some ODFs not from LO, for which LO displays similar or another error.

  • 2015-01-16: now Google Drive seem to be able both preview and convert first file to internal format for editing. That wasn’t case immediately after I uploaded them.
  • 2015-01-17 lol, it can’t again.
#2

Is there a possiblity that you have ever copied the files by ftp without specifying binary mode? I ask because my archive manager reports “Archve type is not supported” for each file.

#3

I just downloaded these files and tested them again with archiver. And they’re fine!
Maybe it’s due to unicode characters in name? I’ll rename them on Google Drive just in case for future.

#4

What kind of tests did your archiver perform? If I try to analyse the wrapped in content.xml with my xml editor I get errors. The content is heavily loaded with direct formatting and has just under 4700 KiByte in unpacked format.

#5

Your “4.2” version: Was it 4.2.7 or earlier? Did you already try recently to reopen your files with 4.2?

#6

@Lupp that was 4.2.4 or 4.2.5 I guess, but not sure. That was latest or previous LO to date (16 june 2014). No, I didn’t try to open them with LO 4.2, because I wanted to use them as templates, and I have other similar files which open fine. And I don’t really care about their contents for now.

#7

@Lupp about tests. I just did 7z t filename.ods and it said file is fine. I mean, it’s not bit-corruption (checksums are fine), it’s how file actually written by LO.

#8

@LogicDaemon - Where did you save the files before you could not open them again? Only on your HDD or also GoogleDrive?

#9

@Lupp - I used version 4.2.4 through 4.2.7., then switched to 4.3.4.1 and now use 4.3.5.2 So far I did not see any problem with my opening older files. In the meantime almost all of my files are ODF format because I started with version 3.3 or 3.4. Therefore I CURRENTLY assume the problem is not LibO related. (OS=XP/SPS3).

I opened 2-3 files created in 4.2 x on an XP PC, on a kubuntu OCwith LibO 4.2.? & 4.3.5 without problems. File transfer: USB HDD & USB stick - no cloud server in between

#10

@ROSt53 I’m also using OOo/LO from pre-1.0, and have thousands of files, which mostly opens fine. But that doesn’t lead to any logical conclusions. And no, I haven’t “save” this file to google drive until posted this question here.

#11

Something which has nothing to do with LibO happened to these files. I used 4.2. from 4.2.4 until 4.2.7 and now use 4.3 and I can access all files created and modified with any 4.2 version of LibO without any problems on XP, Mac, and Linux platforms.

Give the filename a try and use just default character sets and change the name.

Workaround: Use a 4.2 portable version and first open your file and copy and paste the content into a 4.3 file.

#12

@ROSt53 - Did you try to open one of the original files with an old version? My rudimentary analysis of the content.xml from the first one isn’t corrupted in a desastrous (confused) way but there must be wrongly unpaired tags. I get error messages by 2 XML parsers to this effect but couldn’t find the precise positions. Even being retired my time is limited in a sense.

#13

@ROSt53 - I just tried opening the first example with PortableLibO4.2.8 and got the same error as with 4.3.5.

#14

@ROSt53, file is readable with some other software. Google Docs, for example, now even show contents for files I linked (full size and all pages, not with just embedded icon preview). So I’m sure problem is LO-related, and files themselves can be read in current form using some quirks.

#15

I also think the problem is LibO related. The version the file was originally stored with will have caused the error. On the other hand a greater error tolerance (as ‘Google Docs’ may have implemented as you tell us) will not be always the best solution, in specific where also numeric correctness is a main requirement.

We may, however, consider that the user is an important part of the complete system, and ease the task for LibO a bit by using less direct formatting, e.g.

#16

@Lupp First, Files in the example are not done by me from scratch. Both has imported sheets (and they’re still linked; when opened with LO, it will ask to refresh) and only one or two sheets I’m consolidating information to with formulaes.
Second, though it’s offtipic, it’s wrong to blame user for software failures. It’s path of desolation. After all, user must think first, which software to use, right? And they will. If LO will keep being so fragile, it will be avoided.

#17

+1 for portable version suggestion. Still it’s not solution, just easier way to try multiple LO versions.

#18

by the way, I found comments in other questions that portable LO versions are build by third party, and sometimes have regressions or different behaviour from installables. So this can be reason your trials ended in vain.

#19

My one decisive trial was testing the wrapped-in content.xml by the basic standards of XML. I used two different tools for that. Both of the told me there were errors. As I don’t have acces to a fully fetured xml editor, I was not astonished not getting precise error locations.

#20

I have no further idea anymore. Maybe the way @Lupp tried - testing the xml-files - would lead to conclusions. Unforuntately @Lupp needs some better tools. Nevertheless thank to @Lupp for his attempt. I personally have to give up because it goes beyond my expertise.

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