Messages in this thread | | | Date | Mon, 18 Jun 2007 15:47:26 -0700 (PDT) | From | alan <> | Subject | Re: Versioning file system |
| |
On Mon, 18 Jun 2007, H. Peter Anvin wrote:
> alan wrote: >> On Mon, 18 Jun 2007, Bodo Eggert wrote: >> >>> alan <alan@clueserver.org> wrote: >>> >>>> I just wish that people would learn from the mistakes of others. The >>>> MacOS is a prime example of why you do not want to use a forked >>>> filesystem, yet some people still seem to think it is a good idea. >>>> (Forked filesystems tend to be fragile and do not play well with >>>> non-forked filesystems.) >>> >>> What's the conceptual difference between forks and extended user >>> attributes? >> >> Forks tend to contain more than just extended attributes. They contain >> all sorts of other meta-data including icons, descriptions, author >> information, copyright data, and whatever else can be shoveled into them >> by the author/user. > > And that makes them different from extended attributes, how?
The amount of crap. Both seem to become a collection bin for "stuff we need to describe this object". Forks seem to get more piled on, but they are effectively the same thing.
> Both of these really are nothing but ad hocky syntactic sugar for > directories, sometimes combined with in-filesystem support for small > data items.
And both tend to break when you go to a file system that does not support them.
-- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |