Trash spec: directory size cache

[Alexander Larsson]

On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
> hi,
> 
> On 2013-04-15 10:07, Alexander Larsson wrote:
> > 1: Using sha1 seems wrong to me. There is no need to get an even
> > distribution of the keys (like for thumbnail subdirectories), and a sha1
> > is slow to calculate. Also, if you ever look at the file manually its
> > says very little. I would much prefer simple character escape model, say
> > you allow A-Za-z0-9 and everyting else you escape as "-" + the hex
> > digits (like "-2d" for "-"). This is valid desktop file keys, are cheap
> > to calculate and makes most files readable by humans.
> 
> I think you overestimate how slow sha1 is...
> 
> Even still, this is fine to me but there was a concern that the length 
> of the keys could easily get out of hand.  In the 'normal case' of 
> reasonably-named files it will be more readable, though, and faster.

Yeah, i don't think its actually gonna affect real performance, it just
seems unnecessary and makes the files harder to read.

> > 2: Don't store the mtime in a format that needs parsing. Time and date
> > parsing is a very complicated area that is easy to get wrong. And the
> > source is always a stat which is in epoch format, why not just save it
> > in the same format to avoid any day/month order issues, timezone
> > weirdnesses or whatnot.
> 
> We already have a parser for this in the trashinfo file (the original 
> deletion time) although I guess it would be easy to implement the spec 
> without ever parsing this key (since it is strictly informational).
> 
> It may not have been clear in David's email but it is the intention 
> (from our discussions last night) that this timestamp would always be UTC.
> 
> No strong objections to turning it into unix-timestamp-in-UTC though.

NOOOO! The timestamp timezone of a mtime is undefined, and may be
different from the actual timezone of the computer doing the stat()
call, for instance for NFS mounts. There is no reason whatsoever to do
anything to the value returned from stat, as all we do with it is
compare it to a later stat value. Any kind of timezone conversion on it
will not help and may hurt.