[Hint] How did I fix my ODT file

[yoramdavid]

Thank you acknak,

The way you put it was very easy to solve then.
All data was recovered, formatting was messed-up, but that was nothing since I copied it from a backup.

Problem solved, then.
Thanks again.
Regards,

Yoram

[mushysoap]

Hi, I'm hoping someone can help me, pls. Am using Oo2.4, XP SP3, old computer. I was saving file as .doc bec I sometimes use a friend's computer with Word on it. This is my novel so... I am a wee bit panicked. Okay a lot.

Am getting "General input/output error". Have tried: renaming file to .oct (I then get the 'column-width' warning when trying unsuccessfully to open it); zipping and trying the XML thing (no xml file I could see); I searched for backups of course (auto-backup was definitely turned ON but there are no - zero - files I can find anywhere); opening new file, saving, & importing old file into it (nothing happens); etc. I've tried just about everything in this thread to the best of my limited abilities. The file is not "empty" - the length is correct (1,103kb) which is why I still hold out some hope. I suspect I pulled the memory stick too soon, although I'm always very careful; maybe the file was otherwise corrupted somehow, not really sure what went wrong. I guess I should have used native OO format, not .doc.

If anyone can help, pls PM me, I can send that way or via email, whatever you like. Tyvm!!

[Hagar Delest]

If you saved directly from AOO to an USB key, then the file is lost. This is the worst scenario. Always work on HD and copy the file afterward with a file browser. If something goes wrong, you still have the file on the HD to try again.

Moreover the .doc is a binary format so once corrupted, you cannot do anything (or ask Microsoft). That's why it's safer to work in native .odt format (XML based), but anyway, a crash during an AOO access on an external drive is too critical, nothing would have been recoverable.

Do you confirm you've checked the backup folder of the profile ([Tutorial] The OpenOffice User Profile)?

[mushysoap]

Yes, it was empty. Thanks anyway, will not use .doc format or memory stick in future.

[nomnex]

Interesting thread.

I do to have some concern about file corruption, and I have unchecked the following option in the preferences

Load/Save > General > [-] Size optimization for ODF format

The benefit of doing so is that the file "content.xml" loads quickly in a XML editor, on my system (1 GB max. of RAM) and it is readable. But what's your opinion about this setting, and what is the trade-off (say on 100 pages text document with tables and figures)?

In the event I should rather check the "Size optimization preferences" to its default, do I need to re-save all the documents? Thank you.

[nomnex]

It looks like this preference has been removed in LO 3.6.n (I am not sure about OOA)?

https://bugs.freedesktop.org/show_bug.cgi?id=54812

[RoryOF]

Still present in AOO 4.01. Checked by default.

[acknak]

... But what's your opinion about this setting, and what is the trade-off (say on 100 pages text document with tables and figures)? ...

I just leave it at the default setting--I expect it doesn't make much difference either way. I've never looked at the size reduction with a complex document but I expect the difference would be small--something in the neighborhood of 10%.

If I ever need to look at the xml, then either the editor takes care of the formatting, or I can re-format it myself using the "xmlindent" tool.

If the xml is badly damaged, then no tool is going to fix it but I can use an editor to insert newlines that make it somewhat readable.

Edit: PS:

Checking the sizes on some larger files (ODF spec), the biggest difference I see is 6%. For simpler texts (900p book), the difference is even smaller: 1%.

[RoryOF]

The 1% is about what I found on plain text files.

[milonguero]

I've been using OpenOffice happily for years, but I had a major problem with with un-viewable ODT file, a large file about 182 pages, with multiple graphics, and tables, and references, including foreign language characters (in Chinese). The file would apparently load, at least the progress bar completed, but then the content wouldn't show, and the file would crash OpenOffice. I had to force the application to shut down using Windows Task Manager. (CPU idled as high as 95%). Same results opening the problem file in LibreOffice 4. (CPU idles as high as 50%). The problem file was created with AOO 4.01

• Tried as suggested above, to use 7zip to see if any error detected in the file. Changed the name of the file (right-click > “Rename”) to .zip making it openable using 7zip. No errors detected.
• I went looking for an open source solution to the problem, and therefore downloaded and installed open source program called Komodo Edit, hoping to load the “content.xml” file and then re-save as an .odt file. The re-save using Komodo seemed to work, but the error trying to open in either OpenOffice or LibreOffice was not solved. Same outcome as above.
• Komodo Edit was not a complete waste of time. In Komodo, there is a error-check function, and this discovered a problem with the very first line of the file: "line 001: xml error: not well-formed (missing token)" (Problem related to ampersands? Could not figure out if/how Komodo can fix this.)
• Gave up on open source solutions, and resorted to Windows 8 Word. MY SOLUTION: Save problem file to USB flash, copy to a Windows machine running Word8, open the problematic file in Word 8 (ta da!), and then re-save in RTF, ODT, DOC, and DOCX formats, as well as PDF.

As you can imagine, I'm disappointed with the open source universe today: neither open source word processor that I use (Open Office and LibreOffice) could solve the problem created in an ODT file format, nor is there any obvious open source tool out there to import and re-save the file without the problem. The proprietary software worked where the open source was of no avail.

This is for the tech types: Why can MS Word 8 open a problem .odt file (with apparently mal-formed first line) when OpenOffice cannot ?

I suspect the "file optimization in OpenOffice". I've TURNED OFF the compression on save, under Tools > Options > Load/Save > General > uncheck “Size optimation for OpenOffice” (compression algorithm), to avoid problem in future, hopefully. No file compression algorithm is worth this kind of frustration.

[Hagar Delest]

Hi and welcome to the forum!

That's a sad experience indeed. Is your file confidential or not? In latter case, perhaps you can file a bug report: [Tutorial] Reporting bugs or suggestions.
Else, you can contact the devs on their mailing list and propose to send the file to someone wanting to investigate.

[RoryOF]

There are several XML Syntax analysers, many of them online. It would be worth trying content.xml through a few of these just to see what they report.

[acknak]

... Why can MS Word 8 open a problem .odt file (with apparently mal-formed first line) when OpenOffice cannot ?

Because MS has billions of dollars to pay developers to write software that can deal with small syntax errors in the xml. OO uses standard xml parsing code that (as far as I've seen) cannot deal with any syntax errors, even trivial ones.

I suspect the "file optimization in OpenOffice". ...

I very much doubt it. There is no compression going on there, it's just including line breaks and spaces that make the xml easy to read for humans. It amounts to saving a few percent in the file size.

Unfortunately, there are bugs in OO's file handling--sometimes (very rarely) it just generates xml with some kind of error. Doubly unfortunate, because the errors can't be consistently reproduced, the developers don't want to spend time addressing the problem.

If you want to know what the problem is in your file, attach it here (or send it to me), so we can take a look at it.

[Sabsi]

Hello,

I turn again to you, because I do not know what to do. acknak ​​was able to save a portion of the long text that is truncated at the end. I do not know what I can do to possibly still to come on the rest of the text. Can I send the file again someone, so he looks at them? It is very, very important I need the text.

Greetings
Sabsi

[Hagar Delest]

Well, acknak is definitively the expert for such desperate cases. If he wasn't able to recover more of the file, I fear that it's really lost.
Except if he said you by mail that there was something left but that required much work to rebuild.

[Sabsi]

The Text is cut off ... ah, shit -.- three months lost ...

[acknak]

I had to go back and check: what I sent back was everything that was left in the file. There was a second file that apparently came from Recuva, but it contained nothing but zeroes--no useful data there.

[Sabsi]

okay, I think I have to accept that there is nothing more to do, thanks anyway.

[willholder]

Hello Acknak. wondering if you can help. A friend and I were working on a file, created by me in openoffice, yet saved as .doc – since he uses Word – in a dropbox. https://www.dropbox.com/s/xsibsty6prsk4k2/in%20memoriamsWH211113.doc When he opened it it became corrupt. I don't quite understand the steps after zipping a file, AND it's quite important to recover formatting / changes/ comments to the file too (though not pasted images)... Wondering if you could help us. Thanks WH

[acknak]

The zip approach does not apply to .doc files.

As far as I know, there isn't a whole lot you can do with a corrupt .doc file (or any other binary MS Office file--all the more reason to avoid using these formats). However, in this case I was able to simply open the document using LibreOffice (AOO 4.0.1 failed with a read error).

Here's the file I saved from that:

[berk215]

I am having a similar problem. I was finishing up a paper for school when Libreoffice froze. When I tried to reopen the .odt that I was working on, recovery failed and I got a "read-error. error reading file." I tried to follow some of the suggestion posted above, but unfortunately I am new to Linux and Libreoffice and was having trouble following. I attached the file. If anyone could take a look I'd really appreciate the help.

[RoryOF]

Try this:

[berk215]

Perfect! Thank you so much for your help... this has really saved me a lof of time.

[baskaran]

I too facing the same issue. The file works well the day before. Now try to open shows Filter selection option and also not able to have the actual data. Kindly check and recover the file at the earliest.

Thanks in advance.

[acknak]

Sorry, the file contains no recoverable data.

[John_Ha]

Try this:

Rory, acknak

I have been playing with some odt files and this simple technique has recovered the text in all I have tried. Basically, it inserts content.xml from the faulty file into a good odt file.

1 Create a simple odt file called minimum.odt, with just one word in it. Save it as an odt file
2 Unzip the problem file, take a copy of content.xml
3 Insert content.xml into minimum.odt
4 Optional - copy the Pictures folder as well

This is what happens when I do it with berk215's parti serie, limitazioni serie - Goldoni's il filosofo di campagna.odt

[apaj]

Dear all,

I must, first of all, express my apriciation for this thread! For five years now you've been helping people save their hours, days and even weeks of work. Thank you very much and I hope you will be able to the same for me.

The whole thing started with a file I saved yesterday afternoon and wanted to continue working on it this morning. After a double click, Writer said to me:

Code: Select all   Expand viewCollapse view

Data of manifest.rdf could not be read.

It asked me to repair it, yes, why not - nothing happens. Well, actually it does - it gives a blank document with (repaired) proudly sitting on the menu bar - some sort of joke or something. Anyway, I started googling and found this post - once again, amazing, really.

Now, I followed the instructions and thus did some of the recovery myself, but I will need help at this point. First, to eplain what I did.

I unapcked the odt file in question, used RXP to find that in that and that line,column of the context.xml file I have a problem. It repeated several times, five-six. There was ..."argin-bottom="0in" smt... at these places. Since RXP was complaining about missing a white space, all I did was to replace ..."argin... with ..." margin... and it was okay with it. Now, what I have is the following message:

Code: Select all   Expand viewCollapse view

Expected name, but got <EOE> for attribute in unnamed entity at line 2 char 65509 of file

This position that it is reffering to (2,65509) is the last point of the context.xml. It does end quite abruptly:

Code: Select all   Expand viewCollapse view

... text:number-lines="true" text:line-number="1"><style:tab-

So I guess this means that somehow the file got cut... Further, that also means, I have already read on this thread, that some percentage of the content is lost. Nevertheless, it also means that the other percentage is not lost! I also see that the partly repaired file is 3.5 MB in size, while the original one is 8 MB. But how is this possible, when I extracted a file, just change some text, and than packed everything back as it was - where did 4.5 MB go? Anyway, when I try to open the partly repaired file in writer (made it by: zip -r seminarski_partly_repaired.odt * - correct way, right?), I get a blank page again...

Could you please try and help me out save the remaining parts of the file? What am I supposed to do to end the context file "by the book"?

Please find attached two files:
- the original odt file with no modifications - the original I saved yesterday and could not open today: http://www.sendspace.com/file/ie98wv
- the partly rapired odt file (the one I got by zipping back the modified context.xml as described): http://www.sendspace.com/file/jgqjjo

Best regards!

[John_Ha]

I have looked at the original file (http://www.sendspace.com/file/ie98wv) and it seems to be broken quite badly. It is an unfortunate fact that a small corruption in a ZIP file (and .odt files are ZIP files) can mean you lose access to multiple files within it.

1 content.xml is reported as being 136kB uncompressed. When I try to expand it (or test it, I am using 7-Zip) I get an error message "Data error in 'content.xml'. File is broken". When it is expanded, it is only 67kB. So, some error has occurred while compressing the file and lots of data has been lost. When I open it with an xml editor (XML Notepad 2007) I get an error "Error loading ... argin-bottom is an unexpected token ...". This does suggest, as you say, that the "m" from "margin" has been truncated. If so, what else has been lost?

2 When I test layout-cache and mimetype, they are OK

3 When I test manifest.rdf, I get "Unsupported compression method for 'manifest.rdf'", and the same error for meta.xml, settings.xml and styles.xml. I doubt this is actually an unsupported method - it is much more likely that the file is corrupted so it looks as though it is an unsupported method.

4 When I test folders Configurations2 and META-INF, they are OK

5 When I test all the other folders, I get the "Unsupported compression method" error for some, but not all, files in the folders. For example, some of the image png files are OK, some are corrupted.

I then tried to copy the "recovered, but only 67kB" content.xml, and Pictures folder to a minimum AOO odt file so as to replace as many broken xml files as possible. It didn't work this time.

If I was to guess, and I hope I am wrong, I would say that AOO has failed when writing the file and the chance of your getting much out of it is small. The file is quite large - 8MB or so - raising the possibility that it took quite a long time for AOO to write it. Is there any possibility that you managed to interrupt the writing of the file? For example, did you shut the laptop lid and hibernate before AOO had finished writing the file?

I don't know any XML so cannot comment on the contents of the xml files.

How to minimise the effect of its happening it in future.

1 Always take a backup of changed files every day.

2 Always set AutoRecovery to save a copy of the file while you are working on it - it protects against things like power cuts, OS freezes etc. Tools > Options > Load/Save > General

3 Always set Create a backup copy to ON - this keeps the previously saved version of the file. Tools > Options > Load/Save > General

EDIT - ideas added below

4 As suggested by Rory below, do not be over quick to power down or hibernate your computer

5 Be very careful if you save to a USB stick - be sure to Eject it safely.

Why? In order speed up PC when talking to slow things like memory sticks, Windows writes the data to a high speed buffer, and then copies the data slow-time to the USB stick. If you pull it out before the buffer has been written, you lose that data. See Safely remove devices from your computer at http://windows.microsoft.com/en-gb/wind ... r-computer for more information. I think Windows 7 can be set up so as to not to use the write buffer, and always write direct to the USB stick, but I forget how.

[John_Ha]

Now, what I have is the following message:

Code: Select all   Expand viewCollapse view

Expected name, but got <EOE> for attribute in unnamed entity at line 2 char 65509 of file

This position that it is refering to (2,65509) is the last point of the context.xml. It does end quite abruptly:

Code: Select all   Expand viewCollapse view

... text:number-lines="true" text:line-number="1"><style:tab-

So I guess this means that somehow the file got cut...

I think you mean < EOF > which stands for End of File and not <EOE>. This would be consistent with the file being truncated. Note the file length is 65kB as I reported above. It suggests that an EOF Character has somehow got into the file (or some of the file data has been corrupted to be an EOF character) and is being respected as an End Of File marker, so nothing beyond it is being seen. If the EOF character is in the ZIPped file, then the unzipper may not be able to get past it.

[RoryOF]

In addition to John_Ha's advice on saving a file, do not be over quick to power down your computer. Allow it time to flush the write buffers.