very simple datastore reimplementation

Tomeu Vizoso tomeu at
Thu May 8 06:58:53 EDT 2008

On 5/7/08, Jim Gettys <jg at> wrote:
> On Wed, 2008-05-07 at 15:41 +0000, Tomeu Vizoso wrote:
> > On Wed, May 7, 2008 at 11:33 AM, Jim Gettys <jg at> wrote:
> > > Please remember of the need for file names in the on disk structure
> > >  being human readable.  The need for interoperability (not just with
> > >  Sugar) is key.  This wasn't quite clear in your discussion.
> >
> > I was thinking about this at this item:
> >
> > > - Expose the files with a human readable name, for legacy apps and
> > > maybe for backups? Using a FUSE plugin?
> >
> > But I was intending to use the uid in the internal, private file
> > structure as it will be more robust.
> >
> > A FUSE plugin may provide a POSIX API similar to the one in olpcfs,
> > would this be enough to fulfill this concern?
> >
> FUSE doesn't help you either if you take a USB key to some other OS, nor
> if you take the file structure to a Linux system until/unless we succeed
> at making the olpcfs a "standard" on those systems.

Well, if someone access the files through the FUSE wrapper, files will
be copied out of the DS with a name created from its title. This
obviously won't work if someone just copies the internal structures
where data is stored, but the FUSE plugin should make it unnecessary.

> ´╗┐These are not mutually exclusive options: you could concatenate a UID
> with a human readable name.   All I care is that some poor guy who needs
> to find some file has a prayer of doing so without a fancy database
> conversion or some special software.

Yes, we have lots of options there. I just choosed uids for naming
files because it was the most robust and simple solution. If we put
into the equation the human readability requirement, we can find other
ways of naming files.

> Another option is even to generate an HTML page that can be browsed to
> provide an index: but this is less robust if the underlying file ever
> gets separated from such an index page.

Yes, the title is currently stored in the metadata file next to the
actual file, so perhaps some ls-ds tool may be easily coded to present
the files with names based on their title?

As I said, we have many options for improving on this regard.



More information about the Devel mailing list