On 01/06/2012 12:45 AM, ext craig.sc...@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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
