[lkml]   [1998]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Implementing Meta File information in Linux
    In message <>, Feuer writes:
    | Jens-Uwe Mager wrote:
    | > Meta data (on the Mac) is stored in the directory entry of every file, and
    | > is mostly used by the user interface. For example the file types save you
    | > from having to have special suffixes on your file names. I really hate it
    | I thought this kind of thing was what we were talking about.....  What is a
    | resource fork?

    Do you really want to know? :-)

    The resource fork is an indexed structure attached to every file. Finder
    metadata is not stored in this structure; like the data fork (which is an
    ordinary file as non-Macs know it) it is reserved for the application's use.
    Except that for executables the "application" is the OS, and the actual
    code is stored in the resource fork --- think of this as a sort of exploded
    ELF file, although with finer control because little-used routines can be
    placed in their own resources and loaded only as needed.

    An example of desktop metadata that would be stored in the desktop
    database/directory entry is a file comment; an example of application data
    that would be stored in the resource fork would be attribue and font
    information for a word processing file (a' la the old MacWrite program), or
    a user's current cell/cursor position in a data file.

    | > Again it is possible to store such information seperately. But it is much
    | > easier if I rm a file and the comment field just disappears automagically.

    If only the desktop cares about it, perhaps only the desktop should know
    about it. Consider a means whereby the desktop database "server" is
    notified by the filesystem whenever a file is deleted (poll() with a special
    flag on the mountpoint directory, perhaps?); this notification would include
    the pathname of the deleted file. The database server could then adjust the
    database to reflect the file's deletion.

    No, this won't help if the user isn't logged in when a deletion occurs that
    would affect their personal desktop database. Then again, OS/2 has similar
    issues (delete a file with WPS information when the WPS isn't running; not
    all WPS information is stored in extended attributes) and nevertheless
    survives --- in this case by not doing anything about it, hence the market
    for third-party products that clean up the desktop database. On Linux it
    would be better to have a low-priority process running alongside the desktop
    which cleans the database, or perhaps a cron job that runs weekly.

    brandon s. allbery [os/2][linux][solaris][japh]
    system administrator [WAY too many hats]
    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
    Please read the FAQ at

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