Date: Sat, 12 Aug 2000 11:49:26 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
I don't think you realize something.
You argue about resource forks as some abstract interface.
And a lot of other people are arguing about resource forks as a hard, cold
reality of existing filesystems.
Actually, I was arguing for why it's a bad idea (in most cases) to
depend on resource forks, and (by extension) why it might not be a great
thing for the kernel to support them, due to the "attractive nuisance"
argument. But OK, the Unix philosophy is to give ample rope to power
users, either for good, or for evil. So let's assume we're going to
support them. As Stroustroup said when he allowed "," operator
overloading in C++, "If they want more rope, let them have more rope!" :-)
If that's the case, let's look at what the OS/2, SGI XFS, and many of
the other filesystems that have extended attributes need. They are NOT
streams. You can atomically set (and reset) the attribute, but you
can't seek to the end of the attribute and then write to it in order to
append to the attribute.
Hence, for many of these filesystems that support extended attributes.
Using the "fd = sub_open", followed by read/write/lseek calls simply
doesn't map well to what they need at all. So instead, SGI Irix's
extend attribute interface looks like this:
int attr_{get,set}(const char *path, const char *attrname,
char *attrvalue, int *valuelength, int flags);
For NTFS, yes, they are using "named streams", and so the scheme which
you suggested works well. But NTFS is really the exception, not the
rule; most modern filesystems supported "extended attributes", but not
"named streams".
- 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:28 EST