I agree with Alan on this point: The icon simply doesn't
belong in a resource fork, since they meaning of visual
symbols varies from country to country. As an example,
I've heard that the gesture we Americans would recognize
as a request for a ride (by a hitchhiker) would be rather
offensive to an Australian.
> Resource forks need to be stored in your home directory. It is
> not appropriate to look at single user machines, such as Amiga
> and Macintosh and Windows, and then force their techniques for
> resources into a multiple user environment like UNIX.
Sooner or later, we are going to want to add some kinds of
metadata in the inode. Forget about user metadata for just
a moment, and consider ACLs. If I can create a hard link
in my own directory to a file, and then use a ".metadata"
file in that directory to give myself access rights to the
file, this circumvents even the simple file permission
scheme we have now. I don't see how ACLs can be put anywhere
but in the inode. To add to the inode, it seems to me that
we have to make a new kind of filesystem, say ext3. If I'm
right about this, and if we decide we want to add ACLs,
the next question is, what change will we make to the
inode to hold ACLs? Shall we add a single purpose item,
and condemn ourselves to inventing a new filesystem type
for the next change, or do we add something to the inode
that is flexable enough to support new metadata that we
haven't even thought of yet? Isn't this second solution
more consistent with the philosophy of Unix, anyway?
An inode based resource fork could give us this flexability
and, if planned carefully, would allow us to store metadata
that the kernel doesn't care about. Even if we only consider
kernel metadata in a resource fork, some kernels may not
have all metadata features compiled in, so there would have
to be an easy way for the kernel to ignore metadata that
it didn't understand. It is a small step, I think, from
this ability to ignore some kernel metadata to having
metadata that the kernel is never intended to interpret.
The point has been made (and it is correct) that kernel
metadata is fundamentally different than user metadata.
But this doesn't necessarily mean that they two cannot
be stored together. If we decide we need to store kernel
metadata in the inode (and I realize this requirement
may not have been established) we might be able to store
some kinds of user metadata in the same facility without
an unreasonable degree of additional complication. If
an additional type of user metadata would unduly
complicate the inode based metadata scheme, would could
condemn it to implementation through these external
metadata files, without giving up the advantages of
inode based user metadata in those cases where it is
easy.
--- L. Adrian Griffis - KE6CSX - adrian@idir.net- 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