On Mon, 18 Jun 2007, H. Peter Anvin wrote:
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan <alan@xxxxxxxxxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
