Synchronizing xs-0.3 and xo-??? --- backups

Tomeu Vizoso tomeu at
Wed Apr 23 06:50:06 EDT 2008

2008/4/23 Martin Langhoff <martin.langhoff at>:
> 2008/4/23 Eben Eliason <eben.eliason at>:
> > 2008/4/22 Martin Langhoff <martin.langhoff at>:
>  >
>  > > On Tue, Apr 22, 2008 at 10:18 PM, Ivan Krstić
>  >  >  <krstic at> wrote:
>  >  >  >  My solution is the simplest design I could create that allows both
>  >  >  > emergency restore (laptop FS has been trashed, get everything back) and
>  >  >  > individual file restore and sharing via a web interface running on the XS,
>  >  >
>  >  >  Indeed, reading bug 4200 the purpose of the protocol becomes clearer.
>  >  >  What I don't understand completely is the drive behind retrieving the
>  >  >  files via a web interface. I'd think that the main requirement is that
>  >  >  the Journal can talk to it in a simple enough fashion -- perhaps it
>  >  >  was a shortcut to avoid complex work on the Journal?
>  >
>  >  I do believe that was the case at the time.  I think that the user
>  >  experience will be much better if we provide support for entry
>  >  recovery directly within the Journal interface.
>  To complete the picture in my mind of how well/bad rsync will interact
>  with this workload, I am trying to read up a bit on the current
>  datastore implementation, but I haven't found any high-level overview
>  of its internal organization.
>  Is there one?
>  I am not after the API, but after a rough explanation of how things
>  are laid out on-disk. Even if the DS will change, it's important that
>  things work reasonably well with the current DS.

We have in ~/.sugar/default/datastore/store all the files that contain
the "opaque" data of every entry, named by an uuid that identifies the

In ~/.sugar/default/datastore/store/preview are the values of the
metadata property 'preview', png files named by uuid of the entry they
refer to.

In ~/.sugar/default/datastore/store/index are the files that make part
of the xapian index, see the links below for more details. The index
not only speeds up lookups, but also store the whole metadata (in a
quite inefficient way).

That's all. I'm more than happy to answer any other question you have
about the DS.



More information about the Devel mailing list