Type: com.apple.ResourceFork
Subtypes: none
Serialisation: none
Data type: binary containing the whole ‘resource fork’ in compiled form.
Example: <00000100 0004dd24 0004dc24 00000032 00000000 00000000 …> « Ý$ Ü$ 2 …»
macOS: El Capitan, Sierra, High Sierra, and still in Monterey
System use: custom icon storage in macOS; in very occasional 3rd party app support files
App use: limited and diminishing
Document use: still used extensively for thumbnails of images, also in many old documents
Other usage: none

Purpose: contains the ‘resource fork’ of Classic Mac OS, most commonly a thumbnail preview of an image
Information:
Contains the binary contents of what in Classic Mac OS was the ‘resource fork’ of a file. This could contain definitions for menus, dialogs, as well as collections of text, preview or thumbnail images, and executable code.

Long since deprecated, many older documents still contain a varied range of resources, and many images contain small images which were used for previews, in the days before Quick Look. Some current image apps still use these preview images, and still create them when saving image files. They’re also still used to store custom icons for the Finder, apparently.

Unscrambling the data is now not easy, and relies on the long-deprecated command tools DeRez, which decompiles a ‘resource fork’, and Rez, which compiles resources into a ‘resource fork’. See their respective man pages, also those for RezWack and UnRezWack. In recent releases of macOS and Xcode, the path to these tools is /usr/bin, not as stated in the man pages.

Occasionally, apps may mistakenly save resource fork data to the wrong type of xattr. As resource forks can be quite large and have very different content from other xattrs, such files can cause bizarre bugs and problems. Removing the mis-typed resource fork should be curative.

Tools: xattred, xattr, Rez, DeRez

Links:

Thanks to @GeekAndDad for pointing out that they’re still used for custom icons.
Original page: 2017-12-11
Last modified: 2023-02-20