Trash spec: directory size cache

David Faure faure at kde.org
Fri Apr 19 08:13:56 PDT 2013


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>

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 :).

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



More information about the xdg mailing list