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. Cheers Rich. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
