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