<div class="gmail_quote">On 5 December 2012 22:35, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Friday 23 November 2012 02:58:36 Diggory Hardy wrote:<br>
> Dear list,<br>
><br>
> Since this bug — <a href="https://bugs.kde.org/show_bug.cgi?id=245482" target="_blank">https://bugs.kde.org/show_bug.cgi?id=245482</a> — has not been<br>
> addressed and since it makes KDE's trash somewhat incompatible with other<br>
> implementations, I thought I'd have a go at addressing it.<br>
<br>
</div>Great.<br>
<div class="im"><br>
> First, does anyone besides KDE use the ~/.local/share/Trash/metadata file?<br>
> It's not mentioned in the specification[1].<br>
<br>
</div>Right, it's not.<br>
<br>
I actually can't remember (nor find on google) whether an extension to the<br>
trash spec was proposed on the freedesktop xdg list for this. Tobias, do you<br>
remember?<br>
<div class="im"><br>
> Second, what's the best way to solve the problem? It probably mostly occurs<br>
> because other trash implementations don't adjust the metadata file.<br>
<br>
</div>Yes, so this should really be the first approach to this problem: ensuring that<br>
all trash implementations collaborate in storing the size of the trash [in<br>
each trash dir].<br></blockquote><div><br>So you're suggesting that we (or someone) should somehow bring all implementations in line with an updated spec? How would one go about doing this? My aim was to make what KDE does more robust in the face of differing implementations (as well as problems caused by non-atomic writes), although updating the spec at the same time sounds like a good idea. <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> 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.<br>
> (Can we use the filename as a KConfig key?)<br>
<br>
</div>Sounds fine, although you might uncover a few missing escapes in the KConfig<br>
code when doing that, in corner cases (filenames containing [, ] or =).<br></blockquote><div><br>Right. If anyone knows more about this please let me know.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> To get size, first synchronise lines against the 'files' dir (without<br>
> recalculating when names match), then sum the sizes.<br>
</div>> Mostly this should be pretty fast I think.<br>
<br>
It could be, provided that parsing is faster than stat()ing. Maybe true with<br>
cold caches, but not sure it's still true the second time... This would have<br>
to be measured, to avoid choosing a solution that actually leads to worse<br>
performance.<br></blockquote><div><br>I have no idea how file systems store these stats, though I imagine some implementations might require quite a few seeks to stat all the files. Since CPUs are pretty fast I don't think parsing would ever be worse than bad cases of stat-ing (e.g. several thousand items on a slow HDD), which is I presume the ones we're trying to optimise.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> 2) Store the size of each item in the corresponding 'info' file. Should be<br>
> even more robust (we just need to add the line if it wasn't there before),<br>
> might be a good candidate for extending the current specification[1], and<br>
> not very likely to cause problems — except that there's a lot of small<br>
> files to read to get the total size, so it may not be that fast in all<br>
> cases (1000 items on an old HD? NFS/SMB?).<br>
<br>
</div>This sounds slower than simply stat()ing every trashed filed to determine its<br>
size. stat() is a single syscall, while open+read+parsing+close is a lot<br>
more...<br>
This should IMHO neither be done as a workaround nor as part of the spec.<br></blockquote><div><br>Probably true that this isn't a good solution, although don't forget that a trashed item could be a directory containing many files so it should still be faster than bad cases (the problem with benchmarking is that you don't know exactly what someone will have in trash).<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br>
<br>
</font></span></blockquote></div><br>So, I'll wait for a bit more input before really starting. I'm a bit busy at the moment anyway.<br><br>Regards,<br><br>Diggory<br>