On 06/01/2012, at 10:13 AM, David Faure wrote: > On Thursday 05 January 2012 22:21:54 Richard Moore wrote: >> 2012/1/5 David Faure <david.fa...@kdab.com>: >>> Solution 2: how about making this functionality part of QFile itself? >>> No need to "port to another class" anymore, just enable the safety feature >>> by calling file.setUseTemporaryFile(true). >>> This is what I've started doing in the attached patch, but I'd like to >>> gather feedback before polishing it up. >>> One issue is that after doing file.setUseTemporaryFile(true) and >>> file.open(), all the operations on the file object are no longer >>> operating on the given fileName, but on the "internal" temporary file. >>> That's what we want for writing, but maybe it could confuse people that >>> remove() or rename() leaves the existing file untouched? I think it would >>> simply have to be documented: when enabling the feature, all that happens >>> between open() and close(), happens on the temp file. >>> >>> The other question is, would one have to call commit/rollback explicitely, >>> or should QFile::close() (and the dtor) do the committing? >>> And how should one rollback? Explicit file.rollback(), or in the existing >>> file.remove()? >>> Oswald suggested doing that in close()/remove() directly, and getting rid >>> of commit()/rollback(). Opinions? >> >> I think this would be a great feature to have. In general I think >> having it so that the commit is implicit makes more sense, but there >> should be a way for the application to back out. I wonder if we should >> have a concept like abort(), with things running open(), write(), /* >> problem! */, abort() to address this. > > Yes, your abort is what I called rollback. > > (My earlier discussion with ossi concluded that the name abort is too > reminiscent of ::abort which stops the program). > > But the question is if it would be enough (and intuitive enough) to do it > like > this: > file.setUseTemporaryFile(true) > file.open() > file.write() > /*problem!*/ > file.remove() > > And that will set a flag internally so that the dtor knows it shouldn't do > anything. >
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 instance. 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. Nice feature, BTW David. :) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
