I said why above. The resource fork belongs to the *application*, not the
system (except for executables on 68K MacOS). Just as having the OS or your
all-singing-all-dancing-WM-shell-from-Hades scribble stuff into a data file
is unacceptable, it is likewise unacceptable for that to be done to a Mac
file's resource fork.
Your assumption is that the resource fork is a place where arbitrary
programs can hang random metadata about a file. That's how EAs behave on
OS/2, where real file data belongs in the file, not in EAs; but on the Mac,
the resource fork is fully as part of the data file as the data fork and
only the application has the right to play with it. One could argue that
it's not really metadata at all, but a database "view" on a file.
So I guess another question is, what kind of metadata are we discussing
here? Do we want to be able to store the resource fork of a Mac file in our
metadata so as to present a Mac-like abstraction of a file for use in a
theoretical Appleshare-type package? Or do we want somehting like OS/2 EAs
which are specifically metadata for use by the shell/file manager?
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university
- 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/