On 6. jan. 2012, at 22.13, ext Thiago Macieira wrote: > On Friday, 6 de January de 2012 21.27.20, David Faure wrote: >> Exception handling is a new argument though. But doesn't the current QFile >> have the exact same issue then? You start writing, throw an exception, dtor >> calls close, there you go. The use of an internal temporary file doesn't >> change this at all, so I don't see why it should behave differently. > > The file will be closed no matter what, unless you allow for the file > descriptor > to leak. And even if it were to leak, the writing was already done and has > appeared on disk.
Right, QFile doesn't currently offer any atomicity guarantees, but typically what you write gets written to disk, short of catastrophic failures or the disk being removed. The current behavior of the destructor and close() is appropriate for what is there. It is not appropriate to tag an atomically-replace-previous-version on to the close() and normal clean up that the destructor does. > That's very different from executing a rename upon closure. Up until that > point, any observers of the file have not seen any change. Then they do and > see > an in-progress change being saved. > > No, whatever this class is, close() without commit() means "rollback". Right. Keep in mind we are not only saving the new version. We're also destroying a previously known good copy. Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
