text: improve ENOSPC handling when saving

The default atomic save method using rename(2) would correctly fail,
but the calling code would wrongly assume it was because of dealing
with a special (e.g. hard or symlink) file or that some other properties
(e.g. POSIX ACL, SELinux labels, permissions etc) could not be restored.
It would then go on to ftruncate(2) the file, if the following writes
then fail (which is likely if the new file content is bigger or some
other process has used up disk space in the mean time) we lose data.

This should fix it for the common case i.e. regular file where the
rename(2) based method is used. The problem persits when directly
overwriting a file.

It is unclear whether this could be improved/fixed by:

 1) first appending the new file content to the old one
 2) fsync the data (old||new)
 3) deleteing the original file content by overwritting it with
    the previously appended new file content. That is essentially
    moving the new file content from the end of the file to the start.
 4) ftruncate to the new file size
 5) fsync the data (new)

if during 1) or 2) an error would occur we could revert the operation
by doing a ftruncate to the original file size. An error in steps 3-5
would still be fatal.

Another option would be to first write a backup file somewhere.

0 files changed, 0 insertions, 0 deletions