[Development] QFile: writing via a temporary file
Craig.Scott at csiro.au
Craig.Scott at csiro.au
Fri Jan 6 00:45:49 CET 2012
On 06/01/2012, at 10:32 AM, David Faure wrote:
> On Friday 06 January 2012 10:24:04 Craig.Scott at csiro.au wrote:
>> I like the idea that if nothing goes wrong, then close() commits the changes
>> (ie renames the temporary file to the real file name). It makes using a
>> QFile with this feature very transparent and means that functions that
>> accept a QFile will continue to behave in the way they did previously
>> regardless of whether or not this feature was enabled for a given QFile
> This is an excellent point, I'm convinced now.
>> If something goes wrong during the write and you want to discard the file
>> contents you've written out so far, remove() doesn't seem to convey that
>> concept. I would prefer to see a function name that makes things clearer,
>> such as discardChanges() or similar.
> Excellent point too. Much clearer indeed.
> Yay, I love this.
> Note that remove() would still work, too: if it removes the temp file, then it
> also means discarding any changes. But that would be a side effect,
> discardChanges() would be the proper API for doing it.
> Now there's just one question remaining: even if the rule is that all
> operations apply to the temp file, between open and close... what should
> QFile::fileName() return? The temp file name, to obey that rule, or the target
> file name, for symmetry with setFileName()?
> I'm tempted to say: the latter, because the temp file is really internal, and
> to prevent surprises (breaking symmetry with setFileName). Of course it means
> file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :)
If the rule is that all operations apply to the temp file rather than the originally named file, this will potentially change the behaviour of existing functions that accept a QFile as a parameter. I'm leaning more towards having remove() and rename() still operate on the originally named file since that's what those functions have always meant. The temporary file should be an almost hidden implementation detail of the class in my view. It would have a similar effect to buffering the writes and merely delaying when those writes are committed to the original file, but with the added benefit that you can cancel the write right up until the file is closed. Taking this approach, you have no confusion about which file rename(), remove(), etc. apply to because they still apply to exactly the same file they did before (the original/target file).
The temporary file is meant to be an updated version of the real target. If you want to call rename(), you really should first commit any changes and then rename the file. Similarly, if you want to call remove(), you are either removing the original/target or you are wanting to discard your changes in which case a separate function for doing that (as proposed) seems better. Thus, I don't think rename() or remove() should nor need to work on the temporary file.
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
More information about the Development