[Development] QFile: writing via a temporary file

Eirik Aavitsland eirik.aavitsland at nokia.com
Fri Jan 6 09:59:10 CET 2012


On 01/06/2012 12:45 AM, ext Craig.Scott at csiro.au wrote:
>
> 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.
>
>

+1

You may also consider whether, instead of adding a separate API for 
enabling this functionality (e.g. file.setUseTemporaryFile(bool)), one 
could simply add another QIODevice::OpenModeFlag. Say, 
QIODevice::Indirect or something. Because the feature is somewhat akin 
to QIODevice::Unbuffered, ::Append and ::Truncate.

- Eirik Aa.



More information about the Development mailing list