Messages in this thread | | | Date | Tue, 1 Sep 1998 21:03:30 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Implementing Meta File information in Linux |
| |
Date: Tue, 1 Sep 1998 19:07:59 -0400 (EDT) From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Then we must forget about ACLs, privs, the immutable bit... We should be using 14-character unix filenames too. No, make that 8.3 case-insensitive filenames. We must be portable!
There's a difference between metadata which is used by the kernel --- ACL's, privs, the immutable bit, etc. --- and metadata which is used by higher-level applications. Metadata which is used by the kernel or the filesystem should be stored in the filesystem; there's no argument there. And yes, there is an issue with how you preserve ACL entries and privileges with tools like tar and cpio. (There are some solutions; trusted HP-UX has thought about this solution, and has a relatively elegant solution which we can steal.)
However, for metadata which is used by desktops and applications --- icons, file types/class, etc. ---- I don't believe we the kernel should providing such interfaces. In the first place, there's no value added by having the filesystem do it, as opposed to a user-mode shared library. In the second place, it adds unneeded complexity to the kernel and the filesystem. Finally, applications which take advantage of such a scheme become inherently unportable, and this is not particularly useful.
Also, keep in mind that Internet Protocols like ftp and http simply don't support files with multiple data streams. So if we start encouraging the use of such features, we can easily end up up in a situation like MacOS, where you have to use cumbersome tools like binhex before you can ship MacOS files across the Internet without breaking them.
Horrible! Let's not go there.
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |