Create backup file when writing new xml file?

[Thiago Macieira]

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
> filenames.
> 
> 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 [1] 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?

[1] https://plus.google.com/113877326530782588467/posts/SxQBDV6scHj

-- 
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