On Thu, Nov 17, 2011 at 9:24 AM, David Faure <[email protected]> wrote:
> On Thursday 17 November 2011 17:14:06 Robin Burchell wrote: > > On Thu, Nov 17, 2011 at 5:11 PM, David Faure <[email protected]> > 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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
