On Sun, 13 Aug 2000, Rogier Wolff wrote:
>
> the HFS guys made a point of making the filesystem capable of being
> tar-copied. I think that this is a useful feature.
I don't disagree. On the other hand, I have to say that I personally put
ease-of-use before tar-copyability any time.
However, there's a stronger argument against the HFS approach: it
_definitely_ will never work in the schenario that Al outlined - hard
links of complex objects.
Now, HFS doesn't actually have hard links as far as I know, so you may say
"So what?".
The "so what" is simple: are we going to have unified behaviour for
resource forks, or is every damn filesystem that has extended attributes
(whether they be named streams, binary-only EA's, ACL's, whatever) going
to do some ad-hoc name decision for _their_ particular version of their
extensions?
Me, I'd personally prefer to have a _design_. In fact, to some degree
that's actually the only thing I care about.
And the HFS approach fails the "design" criterion. It cannot handle the
NTFS case at all.
Note that some NTFS people have advocated the NTFS design: special
functions for setting and accessing the NTFS EA's. And that is _equally_
short-sighted. It misses the point entirely: I'm not interested in a
HFS-specific hack, and I'm not interested in a NTFS-specific hack.
So what I'm looking for in this discussion an acceptable GoodDesign(tm).
Something that can (a) handle _arbitrary_ extended attributes, no matter
what particular low-level filesystem is underneath and (b) something that
is reasonably intuitive on a user level.
The HFS design fails (a) quite badly. It's just not a possible layout for
the dcache for a hard-linked complex object. Al correctly pointed that out
as an interesting case, and also had the solution for it. But that
solution implies "encapsulating" the whole complex object. Which means
that we cannot spread out the attributes in multiple places.
Personally, I think that spreading out the attributes is also not very
user-friendly, but that's a matter of taste, not a hard cold "this won't
work" kind of argument ;)
Of course, maybe people _want_ different filesystems to just look
different. Maybe a GoodDesign(tm) is not needed. It certainly hasn't been
a big issue so far.
Linus
-
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:30 EST