https://bz.apache.org/ooo/show_bug.cgi?id=126990
--- Comment #18 from Peter <[email protected]> --- here is the Description what the fix contains: ## Fix plan (in order of value) 1. **Stop truncating the original in place.** `docfile.cxx:1858-1860` is the actual data-loss primitive. Replace with: write temp **in the target directory** → sync → `osl_moveFile` over the target. A crash then leaves the *old* file intact — never a zero-filled one. This eliminates the entire class, including the power-cut case that no amount of shutdown handling can catch. Must preserve what the current code path gets right: file attributes/permissions of the original, the `SID_OVERWRITE` / `SID_RENAME` semantics, and the backup-on-failure restore. 2. **Sync before reporting success** — `osl_syncFile` before the `close()` at `shell.cxx:1914`. Ordering matters: sync the data *then* rename. This costs real wall-clock on every save, so it likely wants to be scoped to the document-commit path rather than imposed on every UCB write; measure before committing to placement. 3. **Sync the backup too**, and keep it until the *next* successful save rather than deleting it in `ClearBackup_Impl`. Ordering note: (1) and (2) are **not independent — (2) is a prerequisite for (1).** Implemented in that order for that reason. The atomic rename in (1) is only meaningful if the sibling it renames is already on the medium; without (2) it would swap in a file whose data is still in the page cache, and the same crash would still yield zeros — just under a different filename. Neither is complete alone: (2) without (1) leaves the crash-during-save window, (1) without (2) is not durable at all. What (2) alone does and does not buy: - **Closes the reported signature.** Success is no longer reported until the bytes are durable, so a completed save can no longer turn into zeros in a later crash. It also removes the false "save succeeded" signal, which is what makes the current bug so destructive — users acted on it. - **Residual window: a crash *during* the save**, between the truncate at `docfile.cxx:1858` and the sync completing. That yields a truncated or partially-zero file, not the classic "full size, all zeros". The window shrinks from *write + page-cache writeback delay* (seconds, sometimes much longer under memory pressure) to *write duration only* (milliseconds locally; still seconds on a slow share). Only (1) makes that window non-destructive. Performance: (2) syncs on **every** UCB file write, not just document saves — config writes and extension installs included. That is a deliberate call (correctness first, 2026-07-27); revisit scoping after the fix is out, and keep trunk and AOO41X identical rather than shipping a narrowed variant to one of them. -- You are receiving this mail because: You are the assignee for the issue.
