[lkml]   [1998]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Implementing Meta File information in Linux
    > 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

    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.


    [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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.023 / U:179.776 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site