I've always been unsure why the finderinfo is special and not just
another resource in the resource fork. Compared with a Un*x
filesystem, some parts of the finderinfo are "real" metadata, which is
in the inode in Un*x (e.g. length, times), others could as well be
in the resource fork (type/creator, icon position).
I think this causes unnecessary confusion, just like the entire Mac
filesystem :-) Here's another idea: with each file, associate a
meta-file which is a second regular inode, just that its number is
referenced from the real file's inode, and add an O_META flag to
open(2) that selects which inode to use. (The meta inode may not have
another meta inode attached to it, of course.) This is actually not
unlike the Mac with its separate open() calls for data and resource
fork, where the second is usually only used by the Resource Manager.
Everything else, including a database structure like the Mac's
Resource Manager, can be done in user space. cp(1) can be very easily
tailored to handle both forks, FTP ditto, NFS would need a small
protocol addition, and programs that don't know the metadata will just
ignore it.
olaf
-
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/faq.html