All you never wanted to know about file saving

Geany has a number of options and a plugin controlling the apparently simple operation of saving a buffer to a file. This page gives a more detailed description of the options so that you can make an informed decision which to use, since no one combination is allways “right”.

There is one particular backup of the file saving process that needs to be emphasised first:

The buffer is still available in Geany

No matter what your options settings, if a file save fails you should try to save the buffer to a different device or clear the cause of the failure (disk full, network fault) and try again. You will not lose anything until you close the buffer.

The options controlling file saving are all in the “Various” preferences page.

As that page warns “Warning: read the manual before changing these preferences” and you should read this page carefully too.

The three options are:

• use_atomic_file_saving
• use_gio_unsafe_file_saving
• gio_unsafe_save_backup

This is off by default.

If neither this option nor use_gio_unsafe_file_saving is set, Geany will use simple overwriting to write the file.

Advantages:

• Works on any file irrespective of the underlying file system.
• Fastest, just writes the file once, important for slow remote filesystems.
• Uses the least disk since it truncates the existing file before writing.

Disadvantages:

• Overwrites the existing file.
• If anything goes wrong in writing (disk full, network interruption) the file is likely to be truncated. On some file systems it is truncated to zero length. Geany will give a warning of possible truncation.
• Uses Geany's own code so it can be modified.

If use_atomic_file_saving is set, use_gio_unsafe_file_saving is ignored and Geany will use an atomic file save method. This means that the file is first written to a temporary file, then renamed to the existing file name. On most file systems rename is atomic, that is it succeeds completely or nothing will change, especially on modern journalling systems. This functionality is provided and maintained by the Glib library.

Advantages:

• The existing file is not touched until the rename, which happens after the temporary file has successfully been written. So if the write fails, the existing file should not be lost.
• Fast since it only writes the file once, and then renames it, important on slow remote file systems

Disadvantages:

• Because it writes the temporary file as a new file, it will get the permissions and other metadata (eg execute) of a new file, not those of the old file.
• Does not work on all file systems since rename or rename over an existing file is not supported on all file systems.
• Uses twice as much file space during the process.
• Uses library code so Geany can't modify its behaviour.

This is on by the default, and is provided by the GIO library.

This option attempts to deal with as many of the issues associated with the other methods as it can:

• It attempts to use the atomic rename saving method described above, but tries to address as many issues as it can:
  • it checks metadata of the temporary file and tries to copy the metadata from the existing file,
  • if the metadata is correct, it writes to the temporary and renames as above,
  • if the metadata is not correct, it uses a non-atomic but safe method of:
    • copying the existing file to a temporary file
    • truncating and overwriting the existing file, if this fails the temporary file should be copied back or available, but see disadvantages below.
• It attempts to determine if rename is available on the underlying file system, and uses the non-atomic method if rename fails.

Advantages:

• Deals with the most different conditions, so works the most correctly on the most file systems. That is why it is the default.

Disadvantages:

• There is a long standing bug or design fault in the GIO library that deletes the temporary file from the non-atomic save if writing the data file fails. This means it is no more safe than the simple overwrite method since the previous data is not restored, or even left available for the user to restore.
• The non-atomic save copies data over the network three times (read and write to make the temporary file, write the output file) which can be slow on remote networks.
• Uses twice the disk space.
• Is quite complex.
• Uses library code so Geany can't modify its behaviour.

This is off by default.

The GIO library function used for use_gio_unsafe_file_saving above has an option to make a backup copy of the existing file before overwriting it.

The backup file is located in the same directory as the file being written, and is named the same but with a tilde (~) appended.

Advantages:

• Leaves the previous contents available in case of user error (you meant to do save-as) or failure during the write.

Disadvantages:

• Only works if use_gio_unsafe_file_saving is in enabled and use_atomic_file_saving is disabled (use_atomic_file_saving overrides use_gio_unsafe_file_saving).
• Uses twice the disk space.
• Can be slow on remote filesystems as it may have to read and write data to create the backup if renaming fails.

The Save Actions plugin is distributed with Geany and if it is enabled it provides two actions relevant to this discussion (plus others).

• Autosave
• Backup Copy

Any situation that causes Geany to stop unexpectedly can cause unsaved files to be lost, that includes logout, shutdown, crash etc.

If enabled, the Autosave action saves documents to file periodically. It can be set to save just the current document or all documents, but that may interrupt Geany if many changed documents are saved to a slow filesystem.

Autosave uses the method selected by the options above.

Advantages:

• Reduces the chances of data loss due to crash or erroneous close.

Disadvantages:

• May cause Geany to pause while the save(s) happen.
• Same limitations of the chosen save method, but now happens more often.

Makes a copy of the file every time after the buffer is saved successfully. If the next save fails, this backup is available.

Unlike gio_unsafe_save_backup this plugin works with all saving methods and can be set to save the backup to a different location from the data file, so a slow remote file may be backed up on a fast local disk.

The backup files are named the same as the file being written with the date/time appended. This means each backup file has a different name and won't overwrite the previous backup.

But the backup cache can fill up (especially if autosave is on) and needs to be manually cleaned up regularly.

Advantages:

• Keeps historical backups, which can help to recover from user errors as well as file save failures.
• Works with all combinations of saving settings.
• The backup can be in a different location to the original file.

Disadvantages:

• Keeps historical backups, so it may fill up the disk.
• Adds a copy file overhead to the save operation.