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, [email protected], sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
