if we run out of disk space, some i/o error occurs, or we are just
killed while saving a file, the old contents will be lost.
that's because the old file is opened with O_TRUNC and rewritten.
the "solution" would be not to use O_TRUNC at all. instead, first
write the part that extends beyond the end of the old file (note
that we cannot just seek to the new end and write one byte because
of sparse files) - if that fails to complete, truncate to the old
length (if we crash in between, the old file will have garbage
appended, but at least it's not clobbered alltogether). after the
"extension" was written, overwrite the start of the file with the
new content (if we crash in during this, the file is clobbered, but
that's what you get for using "quick save") and possibly truncate
the file to the new length.
some VFS inherently don't support seeking, so this "slightly safer"
mode is not universally applicable.
a related note: for non-local files, "quick save" is used
independently of the configured save mode. i think the VFS should
tell the editor whether it can do remote renames, so the safe save
modes we can be used in as many cases as possible.