Apache OpenOffice Community Forum

Dear Sir.

One of my Calc file was broken, could you help me to fix it ?

I can open it but all information was gone, the file is important to me, thanks.

Please upload the file showing the problem so that it can be analysed. Use the Upload attachment tab below where you type (128 kB max); or use a file share site, Dropbox or Google Drive for a larger file.

See [Tutorial] How to find and un-delete AOO temporary files for detailed instructions on how to

a) use Previous Versions (W7 and later) to recover previous versions of the file (is there something similar on MacOS and Linux?);

b) recover your file as it was when you last opened or saved it, or as it was when it was last saved with AutoRecovery;

c) find previous versions of the file in the folder it is located in, but which have since been deleted;

d) un-delete the temporary files AOO wrote while you were editing the file, and then deleted. This will recover your file as it was when you last opened or you last saved it.

A file that opens as ### or blanks is damaged - possibly because of over-hasty power off of the computer before the internal buffers in the hard drive had written to disk. Ditto for files that request a Text Import filter. Rarely, if ever, does such filter have any use when opening a damaged file; it usually means OpenOffice cannot understand the file because it is damaged, usually its content has been erased, as indicated by the ###.

You may be able to recover a previous version of the file - see [Tutorial] How to find and un-delete AOO temporary files for detailed instructions on how to

a) use Previous Versions (W7 and later) to recover previous versions of the file ;

b) recover your file as it was when you last opened or saved it, or as it was when it was last saved with AutoRecovery;

c) find previous versions of the file in the folder it is located in, but which have since been deleted;

d) un-delete the temporary files AOO wrote while you were editing the file, and then deleted. This will recover your file as it was when you last opened or you last saved it.

Concentrate on the recovery methods outlined in the tutorial.

https://drive.google.com/open?id=1QsISC ... ggSXTkL1pC

Please find the link for the file, thanks.

Nothing in your file, as I said there would be. Use the Tutorial method to try to recover and earlier version from your computer. Do this as soon as possible.

RoryOF wrote:Rarely, if ever, does such filter have any use

Rory

It is there for whenever the user opens a flat, ASCII text file when it gives the user the opportunity to tell AOO what coding the ASCII file is using. It is also used when a user opens a .csv file, which is a flat ASCII file. Similarly, when a user saves a .csv file it is used to allow the user to specify what coding is used to write the .csv file.

A standard Notepad .txt file does not bring it up because AOO recognises the .txt which tells AOO what coding is being used. If I rename fred.txt to fred.qqq, the ASCII filter is offered.

I am aware of that, John, but my comments were made in the context of a damaged file, where it rarely has any effect; I have altered my earlier posting to make that point.

Sorry, I am not sure your mean because I don't know much about program.
But I am sure the file can be download, could you help me to fix the file.
Thank you very much

casper99994 wrote:Sorry, I am not sure your mean because I don't know much about program.
But I am sure the file can be download, could you help me to fix the file.
Thank you very much

The file can be downloaded. It is "full of empty", i.e. only zeroes (740000 of them). I believe this is how OpenOffice "prepares the ground" to verify that there is sufficient reliable storage space, before writing actual data.
No actual data has been written to the file.

keme wrote:It is "full of empty", i.e. only zeroes (740000 of them). I believe this is how OpenOffice "prepares the ground" to verify that there is sufficient reliable storage space, before writing actual data.

Keme

Good thought.

Do you have any evidence to back up that thought or is it a best guess?

I ask because when we get files full of NUL characters it must happen after any such write of NULs but before the write of the file starts which pinpoints the area of code quite precisely.

John_Ha wrote: Do you have any evidence to back up that thought or is it a best guess?

I ask because when we get files full of NUL characters it must happen after any such write of NULs but before the write of the file starts which pinpoints the area of code quite precisely.

No specific evidence, nor have I inspected the code to determine what actually happens.

Circumstantial evidence at best. (IOW, "Best guess")
Based on the frequent occurrence of "all null" files in the population of faulty files, and very low frequence of partially filled and "null padded" files, I suspect the following:

• After initially writing zeroes, the save routine waits for an OS "acknowledge" before saving data.
• If the file is large and user is in a hurry, the shutdown process interrupts the acknowledge signal.

Can't see the usefulness of the two step save in this day and age, but it may be a relic in the Staroffice-code, from old days of saving to tape devices (forcing character device to behave like block device, or other now forgotten mystic rituals of the past), or perhaps connected to the rights management of some network file services (Novell Netware comes to mind) where you could permit "Create" but disallow "Modify". Then again, those thoughts are only shots in the dark.

Keme

Thanks.

I have some slight evidence for the problem of files with NULs being caused by AOO not correctly handling the interrupt requesting a laptop shutdown, hibernate or sleep, where it is dependent on exactly when during the Save process that the interrupt is received - sometimes it is handled correctly and sometimes it is not. I passed on the information to development but I don't think any work is being done on it.

I only seem to see AOO producing these broken files - does LO do it too? A quick search of the LO bugzilla with ASCII or corrupt picked up nothing relevant.

This may not be due to OO originated code, but to an external code library invoked to handle the building of the archive. Just a guess on my part.

Edit: The source code shows that the building and reading of zips is hadled by a unity helpfully known as "package".

keme wrote:I believe this is how OpenOffice "prepares the ground" to verify that there is sufficient reliable storage space, before writing actual data.
No actual data has been written to the file.

Keme

While I don't understand it, this code from Deflater.cxx, the routine doing the ZIPping, looks very much AOO setting something to NULL. See Contents of /openoffice/trunk/main/package/source/package/zipapi/Deflater.cxx.