Numbered backup or #auto-save# file: which recovery source to trust after a crash

Question

After an abnormal Emacs exit, I can end up with two candidate recovery sources for the same file: a numbered backup such as foo.~3~ (with version-control set to t) and a newer auto-save file #foo#. My goal is to restore the most complete version of the file without silently losing either the last clean saved state or the unsaved edits captured before the crash.

The trade-off I cannot resolve: the auto-save file may contain newer edits, but it can also reflect a partially written, crashed state, while the numbered backup is consistent but older. M-x recover-file shows a confirmation comparing the auto-save against the last saved version, yet that comparison does not tell me whether the auto-save content itself is coherent. My backups are also redirected through backup-directory-alist, so locating the right flattened backup name adds friction. Assume a recent Emacs (28+) with default auto-save-default behavior.

Is there a documented way to compare all three versions (working file, numbered backup, auto-save) side by side, e.g., with ediff-files, before committing to one source? Does recover-file's confirmation prompt expose enough of the diff to judge auto-save integrity, or should the auto-save file be inspected manually first? Is there any Emacs convention for which source takes precedence when timestamps conflict?

Tasadduq Burney · Answer

Direct answer
Trust the auto‑save file #foo# only after you have verified that it contains coherent text; otherwise fall back to the most recent numbered backup foo.~n~. There is no hard‑wired precedence in Emacs – the decision rests on a quick integrity check of the auto‑save.
Confirmed facts

Numbered backups (foo.~n~) are created when version-control is non‑nil and represent a saved, internally consistent state.
Auto‑save files (#foo#) are written periodically; they may be newer but can also contain partially written data if Emacs crashed during a save.
M-x recover-file shows a diff between the auto‑save and the last saved version, but it does not include the numbered backup in its comparison.
You can view all three versions side‑by‑side with ediff-files or ediff-buffers.

Steps to decide

Locate the relevant files:
  
    Numbered backup: C-x C-f foo.~3~ (adjust the number or use backup-file-name-p if backup-directory-alist redirects backups).
    Auto‑save: C-x C-f #foo#.
    If the original file still exists after the crash, open it: C-x C-f foo.

Run a quick integrity check on the auto‑save:
  
    With the auto‑save buffer visible, run M-x view-lossage or simply M-x flush-lines ^C-@ to see if there are null bytes or non‑printable characters.
    Alternatively, run M-x ediff-files on the auto‑save and the numbered backup; look for large blocks of garbled text.

If the auto‑save appears clean (no null bytes, reasonable length, and the diff shows only expected edits), choose it:
  
    Run M-x recover-file and accept the suggestion, or manually C-x C-f #foo# then C-x C-s foo to write it back.

If the auto‑save looks corrupted or you are unsure, revert to the numbered backup:
  
    With the numbered backup buffer visible, run M-x revert-buffer RET RET (or M-x replace-bufferContents with the backup file).
    Then save: C-x C-s foo.

Optional: after restoring, run M-x ediff-buffers on the restored file, the auto‑save, and the numbered backup to confirm you have the most complete version.

When to ask for a missing detail
If you cannot tell whether the auto‑save file is corrupted (e.g., it opens but shows strange characters), ask: "Does the auto‑save file contain any null bytes or appear truncated when viewed with M-x view-lossage?" The answer changes the recommendation: a clean auto‑save → use it; any sign of corruption → prefer the numbered backup.

Numbered backup or #auto-save# file: which recovery source to trust after a crash

1 answer

Direct answer

Confirmed facts

Steps to decide

When to ask for a missing detail

Your perspective belongs here.

0 question comments