[sugar] providing files to activities

Albert Cahalan acahalan at gmail.com
Wed Nov 7 13:21:11 EST 2007


On 11/7/07, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Wed, 2007-11-07 at 11:59 -0500, Albert Cahalan wrote:
> > I'm hearing that files will be provided to activites as hard links.
> >
> > This is not good. It prevents atomic update via rename.
> > Far better is to provide directories, one per file, so that
> > updates can be made atomic. While you can't hard link a directory,
> > you can bind mount it. This is essentially the same, with the
> > extra benefit of not wearing out nand storage.
> >
> > The command line version:  mount --bind srcdir dstdir
> >
> > You can even make the mount read-only, avoiding any need to
> > mess with file permissions to block writes.
>
> Just read in http://utcc.utoronto.ca/~cks/space/blog/linux/BindMounts
> that this is not possible. Is that guy wrong?

He is now. :-)
http://lkml.org/lkml/2007/11/1/363

It's in the mm tree already. Latest mm is here:
http://www.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.bz2

(this has been wanted by core developers for ages,
so no doubts about it going in)

> > Handling groups of files together as a single unit also becomes
> > possible; it happens that I actually need this. (think OSX forks)
>
> How relate bind-mounts to files with resource forks?

I want to treat a group of files as one. I'd rather not
have to tar them up. Thus, I need a directory that looks
like a file. This is in fact how OSX implements resource
forks, at least on newer filesystems. You can in fact
have arbitrary forks, as is done in *.app "files" which
are really directories.

FYI, the content: an image, a background image,
an ASCII data file for settings, etc.


More information about the Sugar mailing list