[Development] QFile: writing via a temporary file

[David Faure]

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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5