Messages in this thread | | | Date | Sun, 13 Aug 2000 10:16:33 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: NTFS-like streams? |
| |
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/
| |