Date: Sun, 13 Aug 2000 20:31:27 -0400
From: Michael Rothwell <rothwell@flyingbuttmonkeys.com>
> For example, suppose you have an EA:
>
> Creator=tytso
>
> Now suppose you do the following:
>
> fd = open("~/Myfile/Creator")
> write(fd, "acox", 4);
> close(fd)
>
> What does the EA contain now? Is it:
>
> Creator=acoxo
>
> or is it
>
> Creator=acox
NT Services for Macintosh actually implements
all resource-fork data in one stream, and provides
structured storage (prob. just a hash table, but I
don't really know) to do it in. It doesn't map
each EA to a separate stream. But, we'll play
your game for a moment. The correct answer is
B, "acox". It doesn't make sense to do anything
but wipe out what is there and replace it when
doing EAs on top of named streams, with a 1:1 EA:NS
mapping. Leaving what is there and overwriting part of
it isn't how EAs work, and isn't how EAs on NSes have
to work.
So what you're saying is that the semantics of read() and write() change
depending on whether your filesystem supports Extended Attributes or
Named Streams. Note that if "Creator" were a named stream, the answer
would be (A).
Is this enough to convince you that trying to emulate Extended
Attributes in terms of Named Streams is terminally broken?!? API's are
more than just the function signatures; they are also about semantics.
If the semantics change in a fundamental way depending on what kind of
filesystem you're dealing with, things are really broken.
The other question which this of course raises is what happens if a
filesystem has *both* named streams and extended attributes? And in
fact, NTFSv5 (shipped with the W2K bug) does in fact have both. This
should hopefully prove to you that Extended Attributes and Named Streams
are fundamentally different.
- Ted
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:32 EST