https://bugs.documentfoundation.org/show_bug.cgi?id=172052
Bug ID: 172052
Summary: Recovery of untitled (never-saved) documents after
crash/forced shutdown restores blank windows — backup
files exist on disk but content is not loaded
Product: LibreOffice
Version: 26.2.3.2 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: framework
Assignee: [email protected]
Reporter: [email protected]
Description:
When LibreOffice is terminated unexpectedly (e.g., Windows forced reboot for
updates) while multiple untitled/never-saved documents are open, the session
recovery on next launch recreates the document windows with their correct names
(e.g., "Untitled 1", "Untitled 21") but the documents are completely blank —
all content is lost from the restored windows.
However, the backup files do exist on disk in the user backup directory at:
C:\Users\<username>\AppData\Roaming\LibreOffice\4\user\backup\
These files are named correctly (e.g., untitled_21.odt, untitled_5.ods) and
contain the full document content. The recovery mechanism fails to reconnect
the backup data to the restored document windows.
Key observation: Previously-saved documents (those with a real file path) in
the same directory are stored as .bak files and recover correctly. Only the
untitled/never-saved documents — stored as .odt / .ods files in the same backup
directory — fail to have their content loaded during recovery.
Steps to Reproduce:
Open LibreOffice Writer (or Calc)
Create several new documents without saving them (they remain "Untitled 1",
"Untitled 2", etc.)
Type content into each document
Wait for at least one auto-recovery cycle (default: 10 minutes), or trigger it
manually
Force-terminate LibreOffice without saving (e.g., taskkill /f /im soffice.bin
or a Windows forced reboot)
Relaunch LibreOffice
Actual Results:
The Document Recovery dialog appears and lists the untitled documents
Recovery proceeds and reports success (or opens the documents directly)
All recovered untitled document windows are completely blank — no content
The backup files with the correct content exist in
...\LibreOffice\4\user\backup\ as .odt / .ods files
Expected Results:
The untitled document windows should be restored with their content loaded from
the corresponding backup files in the user backup directory
Alternatively, if the content cannot be loaded automatically, the recovery
dialog should inform the user that backup files exist at the specific path,
rather than silently opening blank documents
Reproducible: Always
User Profile Reset: No
Additional Info:
Auto-recovery was enabled with default settings (10-minute interval)
The backup files on disk are valid and can be opened manually — they contain
the full document content
This specifically affects never-saved ("Untitled") documents; previously-saved
documents recover correctly
Multiple untitled documents were open simultaneously (20+), all exhibited the
same behavior
A user report on Ask LibreOffice describes the identical issue appearing after
the 7.5 series update: "untitled documents' data are no longer restored after
adverse shutdowns"
Possibly related to Bug 161764 (empty document recovery window on startup after
crash), but this is a distinct scenario: the recovery window is not empty — it
lists the documents — but the restored documents themselves are blank
Suggested Fix Area
The recovery logic in framework/source/services/autorecovery.cxx appears to
successfully write backup copies of untitled documents to the backup directory
but fails to map them back during the restore phase. The untitled documents
lack a persistent file path, so the recovery metadata may not include enough
information to locate the backup file. A potential fix would be to:
During restore, check the backup directory for files matching the untitled
document naming pattern (e.g., untitled_N.odt)
Load content from those backup files into the corresponding recovered document
windows
If a match is found, flag the document as modified so the user is prompted to
save
--
You are receiving this mail because:
You are the assignee for the bug.
