making kioslave/trash size cache more robust

[David Faure]

On Friday 23 November 2012 02:58:36 Diggory Hardy wrote:
> Dear list,
> 
> Since this bug — https://bugs.kde.org/show_bug.cgi?id=245482 — has not been
> addressed and since it makes KDE's trash somewhat incompatible with other
> implementations, I thought I'd have a go at addressing it.

Great.

> First, does anyone besides KDE use the ~/.local/share/Trash/metadata file?
> It's not mentioned in the specification[1].

Right, it's not. 

I actually can't remember (nor find on google) whether an extension to the 
trash spec was proposed on the freedesktop xdg list for this. Tobias, do you 
remember?

> Second, what's the best way to solve the problem? It probably mostly occurs
> because other trash implementations don't adjust the metadata file. 

Yes, so this should really be the first approach to this problem: ensuring that 
all trash implementations collaborate in storing the size of the trash [in 
each trash dir].

> I can think of a couple of workarounds for this: 
>
> 1) Store the size of each item in a line in the 'metadata' file.
> (Can we use the filename as a KConfig key?) 

Sounds fine, although you might uncover a few missing escapes in the KConfig 
code when doing that, in corner cases (filenames containing [, ] or =).

> To get size, first synchronise lines against the 'files' dir (without
> recalculating when names match), then sum the sizes. 
> Mostly this should be pretty fast I think.

It could be, provided that parsing is faster than stat()ing. Maybe true with 
cold caches, but not sure it's still true the second time... This would have 
to be measured, to avoid choosing a solution that actually leads to worse 
performance.

> 2) Store the size of each item in the corresponding 'info' file. Should be
> even more robust (we just need to add the line if it wasn't there before),
> might be a good candidate for extending the current specification[1], and
> not very likely to cause problems — except that there's a lot of small
> files to read to get the total size, so it may not be that fast in all
> cases (1000 items on an old HD? NFS/SMB?).

This sounds slower than simply stat()ing every trashed filed to determine its 
size. stat() is a single syscall, while open+read+parsing+close is a lot 
more...
This should IMHO neither be done as a workaround nor as part of the spec.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5