Create backup file when writing new xml file?

Thiago Macieira thiago at macieira.org
Thu Feb 20 00:57:36 UTC 2014


Em qui 20 fev 2014, às 09:07:46, David Faure escreveu:
> > That's not an atomic operation. There's a brief moment when a file with
> > the
> > original name does not exist anymore.
> 
> I know. But again: how do you use a backup file? You have to open a file
> manager and rename it to the main file name, or you have to use the open
> dialog in the application, with a permissive filter, and open it.
> This is no different whether the main file exists or has been deleted. In
> both cases manual user action is needed to use the backup file.
> 
> If you say such manual action should never be required, then either the
> backup file is useless, or the app needs to provide a GUI for it.
> 
> My conclusion: for a document, user action is required to use the backup
> file anyway, and losing the main file on a crash *is* one of the few cases
> where the backup file actually turns out to be useful. And for an internal
> file (e.g. config file), a backup file is not useful (since the user
> doesn't know about it), so plain QSaveFile is sufficient.

I don't care much about the backup file. It's a good idea to try and be as safe 
as possible, in case there's a problem with saving of the new file and the user 
wants to restore from backup. As you said, restoring the backup requires the 
use of a file manager and direct user intervention.

My problem is only that the a file with the name of the original file name 
ceases to exist for a brief period. What happens if there's a filesystem 
notifier running on that system, watching the directory to reload the contents? 
It might get woken up by the rename of the original to backup and then it 
might decide that the data is gone.

It might mean the difference between a "File has changed, Reload?" dialog and a 
"File was deleted, Close?" one.

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