Create backup file when writing new xml file?
thiago at macieira.org
Sun Feb 16 19:52:36 UTC 2014
Em dom 16 fev 2014, às 17:35:57, Thiago Macieira escreveu:
> Uh... I realise that the question might be about string comparisons. Since
> we're talking about filenames here, it actually bears the question of what
> the filesystem driver on OS X and on Windows consider to be the same. Do
> they restrict to ASCII? Do they apply to the full Unicode range? How about
> the Turkish dotless i?
> Sorry, I don't have a ready answer for you. I hate case-insensitive
> Instead, I'd recommend that save_backup not take as a parameter the
> recommended extension. Simply remove the part after the ending dot, whatever
> it might be, and replace it with .bak.
Musings on saving files with backups, as a possible feature for QSaveFile:
The simplest operation is to write to a temp file, then rename the original to
the backup name, then rename the temp to the original name. However, what
happens if the application crashes between renames? You've got a temp and a
backup, but no file.
So, my next attempt is to hardlink the original to the backup name, then
rename the temp file to the original name. Since link(2) doesn't overwrite like
rename(2) does, I'd need to unlink(2) the backup name before. If the
application crashes right after the unlink, the backup is gone but the
original is still there.
What happens if there are two processes trying to save at the same file? Should
they use a lock file or flock(2) or something? If they don't lock, both will
write to separate temp files. The best case scenario is that they operate in
order: delete, link, rename. If they do the delete+link in order, it also
works. But suppose both do unlink(2) and then both proceed to link(2): one
succeeds and the other fails with -EEXIST. How should this second one react?
Another question is what happens if the application crashes while it has the
temp file open? It will leave the temp file on disk, most likely on the target
directory, so it's unlikely to get collected by a tmpwatcher. We could use
O_TMPFILE to avoid that issue or deleting the file soon after creating it, but
then we can't materialise it later.
linkat(2) with AT_EMPTY_FILE has a warning that says it will only work if the
process has CAP_DAC_READ_SEARCH, which user processes don't have.
Alternatively, Lucas found a workaround in  that uses AT_SYMLINK_FOLLOW and
uses /proc/self/fd/%d to locate the original "(deleted)" name and the path,
but I'm not sure whether this should be allowed in light of the
CAP_DAC_READ_SEARCH requirement of AT_EMPTY_FILE.
And by the way, what happens if the target directory gets renamed? Do we need
to keep a file descriptor open to the directory? Can't we use the file
descriptor for the fie in linkat(2)'s newdirfd?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
More information about the subsurface