[X-Unix] What's in an MP3's resource fork..? [Was: Re: [X4U] ._annoying_files on SMB shares - can I remove them..?]

[James Bucanek]

Stroller wrote on Tuesday, April 20, 2004:
>I wish to remove all non-essential "dot-files" left by Macs on Samba 
>shares, as they're extremely irritating when viewed from Windows boxes. 

The .xxx file type extensions are extremely irritating too.  But we Mac users have learned to live with them.  ;)

Stroller wrote on Wednesday, April 21, 2004:
>I think we've had this conversation before, and I still fail to 
>understand what useful information can be stored in the resource fork 
>that cannot be stored in the data fork.

Nothing -- assuming everyone in the world would structure their data to accommodate, and preserve, information stored there by other applications.  And, as we all know, that's never going to happen.

Resource forks (when properly formatted) contains structured data.  A structure that is defined a manipulated by the Macintosh operating system.  As such, arbitrary small data objects (let's call them "blobs") can be stored in the resource fork of the file, and later retrieved by type and ID.  Since there are, essentially, a unlimited number of types and IDs, all manner of blobs can be organized in the resource fork of a file without any format or name-space collisions; Either with the file's data or any other blobs.

For instance, many web and FTP clients used to add a small resource to a file to indicating the URL the file was originally downloaded from.  Other programs would batch process files and add a high-quality thumbnail as a resource.  User comments, custom icons, bookmarks, preferences, printer settings, processing hints, color profiles, links to media managers, and many other useful bits of information can all be safely stored in a resource fork.  This does not, in any way, impact or interfere with the format of the data fork.  The two coexist happy side-by-side.

Resource forks, like so many aspects of the original Macintosh design, were strokes of pure genius.  Unfortunately they still run into nasty implementation problems when forced to live on the infertile ground of single fork file systems.

______________________________________________________
James Bucanek       <mailto:privatereply at gloaming.com>