Messages in this thread |  | | | Subject | Re: Implementing Meta File information in Linux | | Date | Tue, 15 Sep 1998 13:05:22 +0200 | | From | Olaf Titz <> |
| |
> 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.
Apple _could_ have reserved one resource type or a number of them for usage by the Finder (not: OS) to store things like icon position, etc. just like they reserved the resource type CODE for executables and the whole BNDL mess[1][2] for icon information.
Re-tinking about that, I suspect that another reason is that the original Mac was not slow but slooooooow, and many open files and many GetResource() calls for displaying a directory window was simply too much overhead. This is also the most probable reason for the desktop file in which the BNDLs were copied. > 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.
Right. It _is_ a file with a specialized DB structure.
The distinction between metadata and application data is a bit blurred here, however. Look at TEXT files by programs like BBEdit, which are pure ASCII files in the data fork and carry attributes in the resource fork. You can FTP the file as TEXT and get a text file - still usable but without any font/style information. This is application-specific metadata, so to speak. OTOH, BNDLs are carried by the application, but they are pure metadata in the sense that only the Finder uses them, and only for UI purposes. The program still runs when you remove them (except for cases where it uses its own ICN#s of course).
> 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?
Unnecessary, there are already Un*x Appleshare servers which store a Mac file as three files (the atomicity concerns are addressed by the server application here, which has the exclusive right to access its directories).
For database-structured application files, we have user space libraries. (ICN#s or STR#s in applications can go into their own ELF section, etc. - just need an appropriate linker.)
> Or do we want somehting like OS/2 EAs > which are specifically metadata for use by the shell/file manager?
I think this is more what's needed. E.g. we have enough graphical file managers on Un*x but they are all unusable because of the simple fact that you can't move the icons around in a window and they stay where you put them (although this is arguably stuff for a dot-file in the respective directory). Think about file comments, etc.
olaf
[1] It took many, many years before they came up with a version of ResEdit that could properly handle that particularly braindead structure, and figuring it out by hand was a "challenge".
[2] Any real reason for that "have BNDL" flag out there?
- 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/
|  |