Which conditions trigger the creation of .save files during a nano crash?

Question

GNU nano utilizes a temporary file system to manage unsaved changes, allowing users to attempt data restoration via the -R or --recover flag after an unexpected session termination.
While the editor implements emergency backup mechanisms, buffer management is primarily memory-resident. This creates uncertainty regarding the exact triggers that force a write to a .save file versus scenarios where data remains exclusively in volatile memory until a manual save is initiated.
Specifically, it is unclear if certain termination signals (such as SIGKILL versus SIGTERM) or specific system states consistently guarantee the generation of a recovery file.

Does nano consistently generate a .save file during a SIGKILL event?
What specific internal buffer thresholds or timers trigger an automatic emergency save to disk?

Tasadduq Burney · Answer

GNU nano does not consistently generate a .save file during a crash. The creation of a recovery file depends on the specific termination signal received and the configuration flags used during the session launch.

Signal Handling and Recovery Files
The primary differentiator for .save file generation is whether the process can intercept the termination signal to perform a cleanup routine.

SIGTERM (Signal 15): This is a catchable signal. When nano receives a SIGTERM, it can trigger its internal exit handlers, flush the memory buffer to disk, and create a .save file if unsaved changes exist.
  SIGKILL (Signal 9): This signal cannot be caught or ignored by the application. The kernel terminates the process immediately. Because nano has no opportunity to execute a shutdown sequence, no .save file is generated during a SIGKILL event; any data residing exclusively in volatile memory is lost.
  SIGINT (Ctrl+C): In most configurations, this triggers a prompt within the editor rather than an immediate crash, allowing the user to decide whether to save.

Configuration Requirements
Even during a catchable crash, a recovery file is not guaranteed unless specific conditions are met:

The -B Flag: Nano typically requires the -B (backup) option to be active to ensure that emergency backups are managed. Without this or a corresponding entry in the .nanorc file, the editor may not prioritize the creation of the recovery file.
  Write Permissions: The user must have write permissions for the directory containing the file. If the directory is read-only, the emergency save will fail silently.

Verification Steps
To verify how your specific version of nano (typically 4.0+) handles these signals, use the following scoped tests:

Start nano with the backup flag: nano -B testfile.txt
  Make several edits without saving.
  In a separate terminal, find the PID and send a SIGTERM: kill -15 [PID]
  Check for the existence of testfile.txt.save.
  Repeat the process using kill -9 [PID] to confirm that no recovery file is created.

Missing Diagnostic: To provide a more precise answer, please specify your nano version (nano --version), as recovery behavior has evolved across releases.

Which conditions trigger the creation of .save files during a nano crash?

1 answer

Signal Handling and Recovery Files

Configuration Requirements

Verification Steps

Your perspective belongs here.

1 question comment