https://bz.apache.org/ooo/show_bug.cgi?id=126990
--- Comment #22 from Peter <[email protected]> --- Nice to read from you John. 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. -- You are receiving this mail because: You are the assignee for the issue.
