Trash spec: caching the size of the trash directory

[David Faure]

On Wednesday 19 August 2009, Alexander Larsson wrote:
> On Wed, 2009-08-19 at 10:28 +0200, David Faure wrote:
> > On Wednesday 19 August 2009, Alexander Larsson wrote:
> > > On Thu, 2009-08-13 at 22:17 +0200, David Faure wrote:
> > > > And then it's up to implementations to update that value, when
> > > > adding a file to the trash, restoring a trashed file, deleting a
> > > > trashed file, and when emptying the trash.
> > > >
> > > > Is this OK with other implementors of the trash spec? Can it be added
> > > > to the spec?
> > >
> > > I'm a bit concerned about the performance costs of this. It means that
> > > you need to do a deep recursion into a folder counting its size when it
> > > is trashed. Whereas otherwise trashing a large folder structure is O(1)
> > > it now becomed O(number of files) and does a lot more I/O.
> >
> > Correct. However the alternative (in order to implement a max size of the
> > trash) is that every operation that puts a new file into the trash is
> > O(number of files in the trash), which is clearly a lot worse!
> >
> > Do you agree that the feature "maximum size of the trash" is useful?
> > I know many users who do ;-). Yes, even at the expense of a bit of
> > performance (especially if the size-counting can be done without blocking
> > the user interface, as is the case for us since the actual trash
> > operations are handled in the kioslave which is a separate process; I
> > think it's similar in gio?).
>
> What if instead we store the recursive size of each directory that is
> trashed it in the trashinfo file. Then this could be used to do a pretty
> fast size count. If some app did not do this we could then fall back to
> recursing into it (and perhaps even update the trashinfo file for next
> time).

That would be better than nothing. But if you trash 10000 single files
at the toplevel of the trash (no directories), then the performance will be
as slow as it is today. And for those, reading the size from the .trashinfo
file is probably slower than just doing a stat() on the file itself...

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).