making kioslave/trash size cache more robust

Diggory Hardy diggory.hardy at gmail.com
Fri Nov 23 01:58:36 GMT 2012


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.

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

Second, what's the best way to solve the problem? It probably mostly occurs
because other trash implementations don't adjust the metadata file. 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?) 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; sizes could be
slightly off if another client removes a file then adds another with the
same name, but still fairly robust and avoids the current underflow problem
(since removing an item from the cache doesn't involve subtraction).

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?).

Any thoughts? (I guess I'm largely asking because I've not contributed KDE
code before.)

Best,
Diggory

[1]: http://www.ramendik.ru/docs/trashspec.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121123/134d09b4/attachment.htm>


More information about the kde-core-devel mailing list