Trash spec: directory size cache

[David Faure]

[Reducing CC's, now that people have been notified]

On Wednesday 24 April 2013 14:25:03 Diggory Hardy wrote:
> > > <P>Implementations MUST use a temporary file followed by an atomic
> > > rename()
> > > operation in order to avoid corruption due to two implementations
> > > writing
> > > to the file at the same time. The fact that the changes from one of the
> > > writers could get lost isn't an issue, the cache can be updated again
> > > later on to add that entry.</P>
> > 
> > The cache can be updated again later.
> > How, when, and who should do the update?
> > If multiple file manager implementations are updating the file at the
> > same time, only one of their change will be kept.
> > How can we know there are directories missing from the cache?

Well, if the directory exists and is not in the cache, it's missing :)

> > Should implementation enumerate the whole trash dir everytime to see
> > is there any one missing from the cache?

Yes. Please read the spec, the suggested algorithm does exactly that.
This is necessary anyway, to cope with older implementations, not only due to 
the race condition.

> > If that's the case, the
> > implementation needs to calculate the total size of the missing
> > folders, and add them to the cache.

Yes, as the algorithm does.

> > In the current proposal, we need to check frequently if there are dirs
> > not included in the cache and fix the errors. This looks odds.

That's the same as the previous paragraph, I don't see the difference.

> I for one thought the spec was clear enough. Suggest rewording:
> > Note that if the cache is recalculated by two processes simultaneously,
> > one
> 
> of the updates will be lost; this is not considered an issue since from the
> perspective of either of the updating processes the value obtained was
> correct at some point in their executation and from the point of view of a
> future process reading the cache, the worst case is that the cache read is
> a little older than the value last calculated.

This sounds less clear to me :)
You seem to look at the issue that a directory might "grow" over time. But 
since the spec already suggests using rename() to trash directories (since it 
suggests to only do it for the same partition), then the directory is either 
there (and full) or it's not. So there is no "old value" in the cache.
Either a directory is in the cache, at the time you read it, or it's not (and 
you need to calculate its size "manually"), and then add it to the cache (and 
hope another process doesn't throw that away, but if it does, it will be 
adding it to the cache, or it will happen even later, on the next trash 
operation).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5