Messages in this thread | | | Date | Sat, 12 Aug 2000 16:30:56 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: NTFS-like streams? |
| |
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/
| |