KSaveFile, QSaveFile, QFile

David Faure faure at kde.org
Thu Mar 21 18:02:13 GMT 2013


On Sunday 10 March 2013 16:03:06 Dominik Haumann wrote:
> Hi k-c-d / kwrite-devel,
> 
> Kate uses KSaveFile in KDE 4.10 to avoid data loss during save operations.
> According to [1] KSaveFile will be deprecated in favor of QSaveFile with
> kf5/Qt5.1.
> 
> Unfortunately, using KSaveFile introduces quite some regressions in Kate:
> 
> 1. KSaveFile: Kate/kwrite makes a copy of a file while editing a hard link
>    https://bugs.kde.org/show_bug.cgi?id=316240

I don't see a solution for this one.
The whole point of KSaveFile is to use the atomic rename(2) to replace the 
existing file with the new file, and rename(2) leads to a separate file, thus 
splitting away from the hardlink.

I strace'd vim to see how it handles it: it makes a backup copy first into 
file.txt~, then open+write+close into file.txt directly, then delete "file.txt~"
  [and if file.txt~ exists already, it chooses another name, file.txz~]
OK, so that's why it works with hardlinks.

This works for end-user files, the end user will notice "file.txt" being gone, 
or partially written out, if vim crashed while saving it (or someone pulled 
the plug, etc.), and the user will recover by hand from file.txt~
kate/kwrite could choose to do this too. But it sounds pretty scary for the 
user, to have to realize that the file got truncated, and to look around for a 
backup...
In any case, KSaveFile/QSaveFile also exists for KConfig, where a program 
expects a file to be present, and won't be able to detect this, we need a 
working config file to always be in place, which requires the atomic-overwrite 
solution, instead.

I'm afraid it's one or the other:
* safe code, always a working file available, but hardlinks get splitted up
* possibility to corrupt the existing file, but a backup exists; hardlinks are 
kept.

Given the % of people using hardlinks, I would say they would just have to 
accept that text editors don't preserve them, for the sake of not losing data 
inside the actual file.

Unless someone sees a better solution, this is a WONTFIX for me, 
unfortunately.

[Gotta go, I'll need to look at the other issues later]

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5





More information about the kde-core-devel mailing list