[Sugar-devel] SD card / USB stick support (was: Re: [IAEP] Project Gutenberg, etc.)

[Tomeu Vizoso]

On Thu, Apr 30, 2009 at 09:50, Sascha Silbe
<sascha-ml-ui-sugar-devel at silbe.org> wrote:
>
> Following up on a discussion on iaep...
>
> On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote:
>
>> The SD card cannot do everything the Journal can do, [...]
>
> This is something that we should fix. The way the SD card / USB stick
> support works (in Sugar 0.82.1 on the XO) has bugged me for the past few
> days (e.g. only FAT filesystems will be usable from inside the Journal).
> Maybe it could work roughly like the following (just a brain dump):
> - automount everything, with UUID-based access (/media/by-uuid/<uuid>) in
> addition to the current name-based access (/media/<name>[_<increment>])
> - use "flag files" (empty file with well-known name, e.g.
> ".sugar_datastore_ignore") on the filesystem to filter it out from the
> Journal (so it doesn't index/show the wwwoffle cache)
> - let the user unmount Journal-monitored filesystems from the command line
> (regular umount doesn't work because the fs is busy)
>
> This way SD cards and USB sticks can be used as both a Journal expansion and
> low-level storage expansion (using symlinks to /media/by-uuid/...), even in
> parallel (on the same device).

This has changed quite a bit in 0.84. Removable devices can be mounted
regardless of the filesystem in them, but no metadata will be saved on
the device because we don't write anything else there. Also queries
will be slower because we don't have a database with file data
indexed.

The simplest "solution" would be to provide a view in the journal that
is more clearly a file system layout. If we had the journal split in
action and object views, removable devices wouldn't have action views
and the object views would display the dir hierarchy.

If we want the removable device to behave like one more journal, we'll
need to store a database there. The problem is that people use to yank
these devices before all data has been written, thus corrupting these
data structures.

Regards,

Tomeu

> [book reading activity]
>>
>> [...] it would store meta info for the books, as well as the content type
>> of the book (which the MIME type by itself would not be enough to do).
>
> What do you mean with "content type" if the MIME type is not enough (but
> apparently closely related)?
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJJ+Vg5AAoJELpz82VMF3DawB0H/0XfKa3YT1qwoLSJgTZd6GNU
> 8cC30bkkvyfNPvmbehB0zhhy/fe2AIPbSjqbEQROskKvsSi89tf7Kxhw5FNwyzmy
> yG9s9rgDgCtBAFhUfyY9vTX3Q9dqtt/kGsBWlL5oZ/iUeRUuKZBQIZyHmTA2PkDp
> dGXEomn5FddbjDmWOHDQfT+zOZJPqhB/PH3ZF7Ug3Cz9VXGooiH/k0tAr02aEKX9
> HgnQ71kbo1dXx5tAiXYSSb6QBKoXWhkTKLS6WR9pIjf+HRQVUDhbLFphEHe7SRxz
> A0yf7ddiPw437e/FaGLoz7pcY8gw6tkrLhybSwAsADu1RKkA6WK1tHx+xs7cGB8=
> =ev0l
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>