Trash spec: directory size cache

[PCMan]

I have some questions about the proposal.

On Fri, Apr 19, 2013 at 11:13 PM, David Faure <faure at kde.org> wrote:
> On Thursday 18 April 2013 09:28:32 Diggory Hardy wrote:
>> On Wednesday 17 April 2013 10:12:22 David Faure wrote:
>> > If you find html-in-a-patch hard to read, you can look for "Directory size
>> > cache" at this page: http://www.davidfaure.fr/2013/trashspec_proposal.html
>>
>> Hello,
>> Looks pretty good. Only thing that occurs to me is if too jobs are updating
>> the directorysizes file simultaneously two problems are possible: a read
>> clashing with a write or two clashing writes. Requiring atomic writes (i.e.
>> to a temporary file followed by rename) avoids the first problem and is
>> relatively simple. Clashed writes are probably not worth worrying about
>> (worst case a slow/paused job overwrites a recent file with an old one, but
>> this seems neither particularly bad nor likely from my POV).
>
> Right. We had mentionned this during the meeting, but I forgot to spell it out
> in the spec. Done now, I added:
>
> <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?
Should implementation enumerate the whole trash dir everytime to see
is there any one missing from the cache? If that's the case, the
implementation needs to calculate the total size of the missing
folders, and add them to the cache.
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.
Would you please clarify this part?
Thank you.

> Ryan Lortie wrote:
>> Looks good except for one very tiny detail: you go out of your way to
>> mention that URI encoding is only needed for dealing with '\n' in such a
>> way as it might lead someone to write a buggy implementation that fails
>> to encode '%' itself...
>
> Indeed. Added an explicit mention of the '%' character in that sentence.
>
> http://www.davidfaure.fr/2013/trashspec_proposal.html updated.
>
> I think we're good to go now. Cc'ing the original author of the spec and other
> implementors that I know about, to inform them of the change (and give them a
> chance to react :).
>