.odt corrupted. Shows only #, Hex-Editor 00 everywhere

[kart672]

Hey,

one of my important .odt files turned to dust from one day to the other. When I open the file now I get only a large amount of #-signs. In a hex-editor, every single byte is 00, and there is not one sign of text left.
Renaming to zip doesnt help, the file is just corrupted.

Does anybody know what possibly could have happened to the file? It there any way of getting content back or is the content just neatly cleared, like an empty harddrive? If yes, then why can something like this happen?

I know I should have turned on the automatic update function, but unfortunately I had to resetup my computer some time ago and on installing Open Office I forgot to turn this option on.

[RoryOF]

Nothing to be done directly with the file, I fear. Is there perhaps a randomly named file of roughly the correct date in your OpenOffice Temp directory? If so. move it elsewhere and rename to type .odt (all this at System level), and see if it opens in OOo to give you some/all of your lost file.

What might have happened to the file? Perhaps you closed/powered off your computer before the write buffers had cleared (a common problem, as people close the file and snap lid shut on their laptop). If you were working to a USB device, particularly a USB stick, did you observe the correct removal protocol? USB sticks do go tired, such a stick could be on its way out.

[kart672]

Ah ok I see, yeah that might have happened. I am using a laptop with standby function indeed.
Where do I find the temp folder?

[RoryOF]

The temp folder is pointed to by /Tools /Options/ OpenOffice.org : Paths, within OpenOffice.

Reports suggest that it may be fatal to use the standby or hibernate functions on a laptop when OpenOffice is open/working.

[kart672]

Ok in the directory were only very tiny files of a similar/same date and a few bytes only in size. None of them had any information in it related to my file.
It is too bad that OpenOffice behaves like that. I use Adobe software like Indesign, which can always recover a file, even if the computer broke down.
But I guess this problem can be solved by turning the automatic updates of OpenOffice on, right?

[RoryOF]

This problem may be helped by turning on Automatic updates. However, there are reports of file loss in the event of a crash, be it computer or OpenOffice. I have never suffered such a loss, and I constantly have several presentations and several 80-90K word files in progress at any time over the past few years. Nevertheless I always back up each file being edited morning and evening, so that if I had a crash I would only lose a few hours' work.

[acknak]

I believe that OOo is different in that it saves files in two steps: first, it writes out the current document information to temporary files, then it collects the temp files into the final zipped document archive. If the process is halted before the final step, then everything is lost.

That's just based on my naive observations; I could be completely wrong.

[RoryOF]

I think, when Apache OpenOffice reaches the release 3.4, we then ought to urge a review of the file save protocol; under almost no imaginable circumstances or failure ought a copy of any file be destroyed.

[Hagar Delest]

For the record: 22 page term paper replaced with pound signs. Another one in the list!

[acknak]

Urge away. I agree with you, but the developers have always been unwilling to spend any time chasing a problem that can't be reproduced.

I can't say that I blame them, but maybe It would be worth at least analyzing the actual file-handling code and coming up with some good guesses about what might be happening.

[Hagar Delest]

There is a clear regression that started quite precisely over the time. There are lot of users who have lost data and also confidence in OOo. So the minimum is to check the process for saving.

Reproducible bugs are not the hardest ones and once we know them, we can flag the situation and warn the user. The problem with this bug is that there is something weak that breaks only in specific conditions (but power failure is recurrent). One important thing is that the original file is always wrecked and that is the consequence of a poor saving process.

I do backups myself but not as often as I should and until this problem is fixed, I'll always fear the ###################################...

[acknak]

There is a clear regression that started quite precisely over the time. ...

Maybe coincident with the widespread use of cheap USB thumb drives?

I completely agree: the potential for damage to OOo's reputation is critical. It's quite possible for OOo to get a reputation, just by rumor, of being unreliable, and that can carry more weight than any facts.

At the very least, the saved file should never replace the original file directly; the original file should never be touched until the saved version is completed. As you say, the previous version of the file should never, ever be lost.

[RoryOF]

At the very least, the saved file should never replace the original file directly; the original file should never be touched until the saved version is completed. As you say, the previous version of the file should never, ever be lost.

This is exactly the point, acknak. It doesn't depend on being reproducible, but it does need a change in the File Save sequencing. I can recollect, way back, in pre CP/M days, running into such a problem when writing Z80 assembler. Until I mastered the correct sequence, files were lost.

I certainly think we should push for a revision in a later version of AOO.

[smaz1087]

This has just begun happening to a majority of our users, but not all users and not all the time. We have never heard of it before a few days ago. This is happening mostly on windows XP, and on open office 3.2 and 3.3. I have not yet come across any other program who's files are corrupting in this fashion. The computers are deep-frozen and revert to a saved state on each reboot, so virus's aren't an issue and software configurations are the same now as they have been for at least a year in every case. Why did this just start happening now?

I am going to have the users save parallel copies on another physical server to rule out the storage for the time being.

I don't quite understand the file save sequence, but might an inconsistent link to their share be the culprit in this case?

This is only happening in one of our buildings (250ish pc's) for the time being. If it becomes campus wide we will be in big big trouble.

[Hagar Delest]

I've launched the issue on the dev mailing list and there is some tiny progress: it seems to be under investigation at LibO at least.

I haven't been flamed by the devs so I take that as a very positive step: it tends to prove that they admit there is something wrong somewhere...
Better than the first reply I got in my bug report.

[floris v]

Something like this might be behind it all:
Warning: Pseudo Pascal code ahead.

Use a file object with an internal buffer and buffer size field.

Code: Select all

myfile := fileobject.create (filesize); // initialises the object, setting the buffersize variable to filesize and allocating space for a buffer with size filesize and zeroing all bytes/words in the buffer
try
  myfile.getdata (document); // set the number of bytes/words to be written to disk and write the file data from memory to the buffer
except
  anything might go here in terms of error handling
finally
  myfile.close; // this method would typically write any data still in the buffer to disk and then destroy the buffer and object
end;

Now imagine that the power loss occurs after object creation and that by some resulting glitch the getdata method is aborted after setting the number of bytes/words to be written but before copying the data and an error is thrown. The program will then continue with the finally block - writing the content of the buffer to disk.