Messages in this thread | | | Date | Tue, 22 Jun 1999 18:15:52 -0700 (PDT) | From | a sun <> | Subject | Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and loic |
| |
So before we design filesystems that support multi-forks, let's please think about how they will be used, and how they will interact with current systems that don't really support multiple forks, and in fact are quite hostile to the whole concept. What's
isn't this one of those perpetual internet wheel of time discussions? in any case, i'm with you here. all of the unix-based appleshare servers that use posixy filesystems that i'm aware of use a .AppleDouble/.resource/.whatever. interface to the filesystem. of course this makes splitting forks a problem if you're not careful, but that's always going to be the case unless you stay on a filesystem that has a concept of forks to begin with. apple, of course, chose the latter course by using the non-posixy parts of hfsplus.
having said that, i actually think that keeping associated bits bundled together would be a good idea in a number of cases. i'm particularly interested in appleshare (although i'll be solving those issues by going the database route), but i think being able to give the filesystem hints on what to keep together would be a good idea in general. however, i would much rather have something like an hfs-style interface to that bundling. that way, we can specify things like "mount -o afpd" and get the .AppleDouble layout that i want or "mount -o bundle" and have .bundle directories everywhere. so, for AppleDouble style forks, we get the following: d/file d/.AppleDouble d/.AppleDouble/.Parent d/.AppleDouble/file
for something that wants to handle arbitrary forks, we can have the following: d/file d/.bundle d/.bundle/.Parent/fork1 d/.bundle/.Parent/fork2 d/.bundle/file/a d/.bundle/file/b d/.bundle/file/c
if you want to bundle some info together, you just create something in the special dot directory. that way, something like reiserfs will get auto-tuned for any filesystem usage that's desired, all the standard unix commands still work, files are transferrable to non-fork understanding filesystems, and your program can work without modification on less hintable filesystems.
-a
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |