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

[Stroller]

On Apr 21, 2004, at 1:15 am, James Bucanek wrote:

> 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.  ;)

Ah! I think we'll have to agree to disagree on this one. It's perhaps 
illustrative of my background, but I find .xxx file extensions natural 
& intuitive.

> 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...

Perhaps so. But, as you say, most filesystems don't understand them. I 
can see the value in having a repository of "miscellaneous and useful 
`stuff'" to be associated with a file, as long as application 
developers don't insist in putting *essential* stuff in there. I think 
this thread has given me a better appreciation of resource forks; I 
read some time ago about Hans Reiser's filesystem, and I now realise 
that resource forks are very similar to something that he wishes (or is 
trying) to implement.

However, in a largely single-fork world it should, I believe, be safe 
to assume that the resource fork can be lost without damage.

Stroller.