File full of #### bug has been fixed

[John_Ha]

See Issue 126990 - File saved normally then opened and filled with # which reports that the file full of #### bug has been fixed. The description of the bug is as follows (thanks to Peter for taking the time to explain it).

What's happening, in plain terms.

When you save, the bytes don't go straight onto the disk. Windows keeps them in memory for a while and writes them out when convenient — usually within a few seconds, sometimes much longer if the machine is busy. That part is normal and every program lives with it.

Two things made it destructive here.

AOO told you the save had succeeded while the data was still only in memory.

It never asked the operating system to actually commit it to the disk. So the progress bar finished, the document looked saved, and you carried on — but if the machine lost power or froze in the next few seconds, those bytes never landed.

Worse, AOO erased your existing document before writing the new one.

It emptied the file to zero length first, then streamed the new version into it. So during the save there was a moment when your old document was already gone and the new one wasn't on disk yet. That is why people lose a 22-page paper rather than just the last ten minutes of edits — the previously saved content was deleted as the first step.

What you're left with is a file of the right size whose contents were never written. The file system records "this file is 27,605 bytes" but the data was only ever in memory. Windows deliberately reads unwritten areas back as zeros, so you get a file full of nothing. It isn't a zip archive any more, so AOO doesn't recognise it as a document, falls back to treating it as plain text, and shows the ASCII import dialog — and zero bytes display as #.

What we changed

AOO now waits for the disk. The save isn't reported as successful until the operating system confirms the data is physically written. If that confirmation fails, you get a save error instead of a false success.

AOO no longer deletes your document to save it. The new version is written next to the old one under a temporary name, confirmed onto the disk, and only then swapped into place in a single step the file system cannot leave half-finished. If anything interrupts at any point, your previous document is untouched.

The practical effect: a completed save can no longer turn into a zero-filled file, and a crash during a save now costs you at most that one save instead of the whole document. Saves may be marginally slower, because waiting for the disk takes real time. That was a deliberate trade.

Thank you Peter and all in Development who contributed to this big fix and to Rory O'Farrell who first suggested to me that he suspected it happened when a user slammed the laptop lid shut immediately after saving a file.

[Hagar Delest]

That is excellent news indeed.
Sad that AOO users had to wait years for that to happen when LO did the job at the very beginning. And now that I've had a taste of LO, I won't look back.
The now former save process was a bit weird. Without performing a deep risk analysis, it is quite obvious that it was not very safe. Or maybe it dated a time when there was no writing cache. But still, removing the original file before all lights were green was a gamble.
Quite a lesson learnt.

[RoryOF]

While this is great news, it may not be available until the coming release which is being worked on, no release date yet.