Dear list,<br><br>Since this bug — <a href="https://bugs.kde.org/show_bug.cgi?id=245482">https://bugs.kde.org/show_bug.cgi?id=245482</a> — 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.<br>
<br>First, does anyone besides KDE use the ~/.local/share/Trash/metadata file? It's not mentioned in the specification[1].<br><br>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:<br>
<br>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).<br>
<br>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?).<br>
<br>Any thoughts? (I guess I'm largely asking because I've not contributed KDE code before.)<br><br>Best,<br>Diggory<br><br>[1]: <a href="http://www.ramendik.ru/docs/trashspec.html">http://www.ramendik.ru/docs/trashspec.html</a><br>