Trash spec: directory size cache
Jerome Leclanche
adys.wh at gmail.com
Mon Apr 15 03:17:14 PDT 2013
Do the keys accept %? uri-encoding them would be the obvious solution here.
I'm also very uncomfortable with the sha1 bit, but apart from that
everything looks good.
J. Leclanche
On Mon, Apr 15, 2013 at 9:11 AM, David Faure <faure at kde.org> wrote:
> On Monday 15 April 2013 10:19:55 Bastien Nocera wrote:
> > Em Mon, 2013-04-15 às 10:07 +0200, Alexander Larsson escreveu:
> > > On sön, 2013-04-14 at 23:48 +0200, David Faure wrote:
> > > > To implement a maximum size for the trash directory, one needs to
> check
> > > > the
> > > > size every time a new item is being trashed. With the current spec,
> the
> > > > only solution is to do a recursive traversal, which is pretty
> > > > expensive. To make this efficient, we need a cache.
> > > > My initial idea of a global "total size" cache doesn't work well with
> > > > older
> > > > implementations which don't update that value, so it gets out of date
> > > > quickly.
> > > >
> > > > Instead, Ryan Lortie and I came up with the following idea, which we
> > > > would
> > > > like to standardize into the trash spec:
> > > >
> > > > For files, we get the file from stat. For dirs, we use a cache:
> > > > in every trash directory, a metadata file is created, with one entry
> per
> > > > directory (that was trashed by the user).
> > > > That entry contains the total size in bytes of the directory, and the
> > > > modification time of the trashinfo file [*].
> > > >
> > > > The metadata file uses desktop file syntax, where the key is the
> > > > directory
> > > > name, and the value is a pair: size, and mtime.
> > > >
> > > > However the desktop file standard restricts the available characters
> for
> > > > keys, so instead of just writing out the directory name, we write the
> > > > sha1 of the directory name (a bit like the thumbnail spec uses sha1s
> > > > too).
> > > >
> > > > In summary, it would look like this:
> > > >
> > > > [Directories]
> > > > # One entry per sub-directory of the "files" directory
> > > > # key = sha1 of the directory name
> > > > # value = size in bytes, timestamp of the trashinfo file, in UTC
> > > > cb58e5c11a6802db43fd82ca8d3c7393353c0eab=25383,2009-07-11T20:18:30
> > > > f1d2d2f924e986ac86fdf7b36c94bcdf32beec15=2315,2012-04-12T10:05:20
> > >
> > > In general this sounds good to me. I have two minor objections:
> > >
> > > 1: Using sha1 seems wrong to me. There is no need to get an even
> > > distribution of the keys (like for thumbnail subdirectories), and a
> sha1
> > > is slow to calculate. Also, if you ever look at the file manually its
> > > says very little. I would much prefer simple character escape model,
> say
> > > you allow A-Za-z0-9 and everyting else you escape as "-" + the hex
> > > digits (like "-2d" for "-"). This is valid desktop file keys, are cheap
> > > to calculate and makes most files readable by humans.
> >
> > Or base-64 encode the directory name. Even if that fails the "readable
> > by humans" test, at least it'll avoid slightly differently buggy escape
> > sequences).
>
> Base-64 leads to huge output. I think escaping with '-'+hex is fine
> (possibly
> faster, more readable, and not as big). I don't see the "buggy" argument.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130415/2e4ef260/attachment-0001.html>
More information about the xdg
mailing list