Brandon S. Allbery KF8NH wrote:
> In message <35FC08B3.576A86DF@his.com>, 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?
> +--->8
>
> 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.
> +--->8
>
> 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] 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/faq.html