On 11/7/07, Tomeu Vizoso <[EMAIL PROTECTED]> 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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel