[Development] QFile: writing via a temporary file

Craig.Scott at csiro.au Craig.Scott at csiro.au
Fri Jan 6 00:24:04 CET 2012


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.faure at 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






More information about the Development mailing list