[Development] QTemporaryDir API

[Charley Bay]

On Thu, Nov 17, 2011 at 9:24 AM, David Faure <david.faure at kdab.com> wrote:

> On Thursday 17 November 2011 17:14:06 Robin Burchell wrote:
> > On Thu, Nov 17, 2011 at 5:11 PM, David Faure <david.faure at kdab.com>
> wrote:
> > > The method already asserts if the path is empty or is ".", we could
> make
> > > that stricter to catch more bugs (error instead of debug-mode-only
> > > assert, and refuse more paths, including the home dir).
> >
> > Why does it need to be static at all, as opposed to the API user being
> > able to explicitly remove the QTemporaryDir they've created
> > themselves? No room for bugs, or removing the wrong directory.
>
> That's what the non-static remove() is about.
>
> But the static removeDir covers other cases, like the ones I mentionned at
> http://developer.qt.nokia.com/forums/viewthread/9860/P15 :
>

IMHO, anything that hits the file system should be centralized.  It's
"outside the process", and  potentially "dangerous" (especially any
non-read action).

I like the QTemporaryDir idea.  I would like to keep it, but merely "move"
the actual file-system-hitting-stuff to some central QFileSystemHitter
class (which would be used in the implementation of QTemporaryDir), so an
application can breakpoint, centralize, check-point, or otherwise "control"
what file system hits occur.

For example, the QFileSystemHitter::RemoveDir() could receive *every*
"remove-dir" operation, and "filter" to only *actually* remove those dirs
which the application gave "permission" to remove.  In this case, the
application may set "these-dirs-you-control", and the QFileSystemHitter
would *fail* on any operation that is not in those subdirs.

We hit the file system a lot, and that's the design we have.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111117/cd41cb10/attachment.html>