Trash spec: caching the size of the trash directory

[David Faure]

On Friday 21 August 2009, Alexander Larsson wrote:
> I'm a bit scared about doing incremental updates of the cached total
> value. Say you trash a one meg file, you read the cache file and take
> the total there, add one meg and then write it back. This is ripe with
> race conditions for concurrent trashes

Indeed. In fact, we just implemented a mechanism to avoid races between
trash processes. Rather than lock files, which can become stale easily,
we had the idea of using dbus registration, which has the feature of ensuring 
that only one process can get hold of a given service name at a given time,
where desired (in dbus terms: "queue and allow replacement", which seems
to be flags==0 in RequestName()). 

We could agree on a dbus service name like "org.freedesktop.private.lock-
trash" for this, and this way only one "trash" implementation could do stuff 
at a given moment, using the standard "get lock, perform work, release lock" 
mechanism to avoid the races. (the "private" in the name is so that users look 
away and don't try to treat this like a publically-accessible dbus service).

http://lxr.kde.org/ident?i=KInterProcessLock for the implementation.

> [if some app] forgot to update the size cache, [...]

I know there's going to be a small transition period where not all 
implementations update the size cache, but IMHO that's not critical;
the "your trash is full" warning will come up a bit too late or a bit too
early, no big deal. If in the long run all implementations implement this,
that's fine.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).