Resource fork

For the hidden files starting with "._", see AppleDouble. Not to be confused with .DS_Store.

A resource fork is a fork of a file on Apple's classic Mac OS operating system that is used to store structured data. It is one of the two forks of a file, along with the data fork, which stores data that the operating system treats as unstructured. Resource fork capability has been carried over to the modern macOS for compatibility.

A resource fork stores information in a specific form, containing details such as icon bitmaps, the shapes of windows, definitions of menus and their contents, and application code (machine code). For example, a word processing file might store its text in the data fork, while storing any embedded images in the same file's resource fork. The resource fork is used mostly by executables, but any file can have a resource fork.

Design

The concept of resources and resource forks was conceived and implemented by Apple programmer Bruce Horn. It was inspired by Smalltalk's dynamic and object-oriented programming environment, and specifically the object-oriented virtual memory system OOZE designed by Ted Kaehler.

In classic Mac OS, resources and resource forks served several purposes:

• Reducing the RAM usage of large data, such as bitmaps, by implementing a form of virtual memory: resources can be loaded from disk into memory on demand and unloaded when no longer needed.
• Providing a way for non-programmers to perform internationalization and localization or to change an application's graphical elements, without needing access to the source code.
• Storing the Finder's Desktop Database, which stored file type associations and icons as resources.
• Allowing applications to distribute nearly all of their components in a single file, reducing clutter and simplifying application installation and removal.

File system support

Further information: Macintosh File System, Hierarchical File System (Apple), and HFS Plus

The resource fork is implemented in all of the file systems used for system drives in the classic Mac OS (MFS, HFS and HFS Plus), and in the macOS-only APFS. The presence of a resource fork makes it easy to store a variety of additional information, such as an icon that the desktop should display for that file. While the data fork allows random access to any offset within it, access to the resource fork works like extracting structured records from a database.

The Macintosh file systems store metadata distinct from either the data or resource fork, such as the creation and modification timestamps, the file type and creator codes, and fork lengths.

Some files have only a resource fork. One example is a font file in the classic Mac OS. Another example is a Classic 68k application, where even the executable code is contained in resources of type 'CODE'. Later PowerPC binaries stored the executable code in the data fork.

Since resource forks were supported only on Macintosh file systems including MFS, HFS, HFS Plus, and APFS, they could not be copied to the file systems of other operating systems. The Mac BinHex and MacBinary formats were invented to encode resource and data forks into one file, for transfer between systems. A/UX supported resource forks on Unix file systems via the AppleSingle and AppleDouble formats. Starting with Mac OS X Tiger, AppleDouble was used to store resource forks on file systems such as Windows SMB shares and FAT32 (File Allocation Table) volumes.

In the HFS Plus file system, settings can be made to allow other forks in addition to the data and resource forks, to create a "multi-fork" application.

As of August 7, 2002, Apple recommended that developers should not build resources into resource forks in Mach-O binaries on Mac OS X.

Resource identifiers

Each resource has an OSType identifier (a four byte value), an ID (a signed 16-bit word), and an optional name. There are standardized resource types for dialog boxes (DITL), images (PICT), sounds (snd ) – and executable binaries (CODE) which, until the advent of the PowerPC processor, were without exception stored in the resource fork. Subroutines for rendering windows are stored in their own type of resources (WDEF), and subroutines for rendering menus in theirs (MDEF). This arrangement enabled users to easily customize not only individual applications but also the operating system itself, using tools such as ResEdit to modify the resources of an application file or any of the system files.

Within an application or other code, resources can be loaded simply using a combination of their type, ID or name, without regard to how and where they are stored in the resource fork. The client is returned a handle to the loaded resource which can then be accessed like any other heap-based data. The OS component that facilitates this is the Resource Manager. In addition to abstracting the details of the data storage from the data, the Resource Manager also arranges sets of open resource forks into a stack, with the most recently opened file on top. When trying to load a resource, it will look in the top of the stack first, (perhaps the current document's resource fork), then the next one down (the application's resource fork), then the next one (system resource forks). This arrangement is very powerful – it permits local resources to override more global ones lower down – so an application can provide its own icons or fonts in place of the standard system ones, for example. It also allows an application to load resources from the system using the same API as any other resource, without regard to where or how that resource is stored – to the application, all resources are equally available and easy to use. The system reserves resource IDs in a certain range to help avoid resource conflicts arising from this. Resource Manager APIs allow the programmer to manipulate the stack and modify the search behaviour.

Editing

"Resource editor" and "Resource editing" redirect here. For editing resources in Microsoft Windows, see Resource editor (Windows).

As the resource fork can be edited with a resource editor such as ResEdit, it can be used to localize and customize software. In addition, most resource editors allow visual editing of data. In macOS, it is possible to use resources when developing an application. However, if the application may need to be used in UFS, it is also possible to configure it so that the entire resource fork is moved to the data fork, using the Raw Resource File setting. The integrated development environments distributed for free by Apple Inc., which include MPW and Apple Developer's Tools, include a compiler called Rez. This uses a dedicated language, also called Rez, which can be used to create a resource fork by compiling source code. A decompiler, DeRez, which can be used to change a resource fork back into Rez code is also included.

In the structure of the resource fork, there is a piece of data called a "resource map" which stores the positions of resource data items. This can be used to allow random access to resource data based on the defined IDs and names. The resource fork can be thought of as consisting of essentially two objects, the resource map and the resource data itself, but in fact each data type is a hierarchical structure which stores multiple items of data. The format in which the information in the resource data is stored is defined based on the types of information, which are known as "resource types." Resource data often makes references to other types of data.

Accessing

Resource forks appear as the extended attribute com.apple.ResourceFork.

Previously resource forks were accessed via the 'Resource Manager' API. This API is now deprecated.

Under the deprecated API:

1. When a resource fork is accessed, data including the start position and length of the resource data and resource map is read in from the header.
2. If a resource type to read in has been specified, a check is performed to make sure that type is present in the resource list, and the number of items of data containing that type and their offsets in the resource reference list from the start position of the resource map is found.
3. The resource ID, the offset of the resource name, the resource properties, and the offset of the data from the start position of the resource data is found.
4. If resource data with the specified ID or name is present in the resource data, the offset obtained above is accessed, the data length is found, and all the data stored there is read in, and returned as the return value.

File Manager APIs such as PBOpenRF() also allowed access to the raw resource fork; however, they should be used only for applications such as copying a file – Apple strongly warns against using the resource fork as a "second data fork."

From the POSIX interface, the resource fork could be accessed as filename/..namedfork/rsrc or as filename/rsrc; the shorter form was deprecated in Mac OS X v10.4 and removed completely in Mac OS X v10.7.

Types

The type codes below, like the above datatypes, are used as type identifiers for more than resource forks themselves: they are used to identify files themselves, to describe data in the clipboard, and much more.

Types must be 4 bytes long, so types like snd and STR actually have a space (0x20) at the end.

Name of resource type	actual name	Description
alis	alias	Stores an alias to another file, in a resource fork of a file whose "alias" attribute bit is set
ALRT	alert	Defines the shape of an application alert box
APPL	application	Stores application information
BNDL	bundle	Defines data such as a file type icon used in an application
cicn	color icon	Defines a color icon used in data
clut	color look-up table	Defines a color palette used in data
CNTL	control	Defines the details of a component positioned in a window
CODE	code resource	Stores the machine code for the program
CURS	cursor	Defines the shape of a monochrome cursor (8 × 8 bit square)
DITL	dialog item list	Defines a component of a window
DLOG	dialog	Defines the shape of a dialog box for an application
FREF	file reference	Defines a file type handled by an application
hfdr	icon balloon help	Defines the contents and shape of the balloon help displayed when the cursor hovers over the file in the Finder
icl8	8-bit icon list	Defines an icon displayed in the Finder
icns	32-bit icon list	Defines an icon displayed in the Finder
ICON	icon	Defines a monochrome item used in data
kind	file description	Defines a description of a file type
MBAR	menu bar	Defines a menu and menu bar for an application
MDEF	menu definition	Defines a menu for an application. Can also be used to define menus with complex shapes such as color palettes.
MENU	menu	Defines the menu items in an application
MooV	movie	Stores a QuickTime movie
open	open	Defines a file type which the application can open
PICT	picture	Stores a PICT image contained in the file
PREF	preference	Stores the environment settings for an application
snd	sound	Stores a sound used in the file
STR	string	Stores a string or hexadecimal data used in the file
STR#	string list	Stores multiple strings used in the file
styl	style	Defines style information, such as the font, color and size of text
TEXT	text	Stores text
TMPL	template	Describes the data format of a specific resource type, to control how ResEdit and other resource editors display resources of that type
vers	version	Defines the version or region of use of the file
WDEF	window definition	Defines a window for the application. Windows of an unspecified shape can also be defined.
WIND	window	Defines the shape of an application window

Editors

ResEdit

Distributed free of charge by Apple. Can be used for visual editing of resource data. If the structure of data is known, it can display a range of different types of data in a visual format. Does not run on modern macOS.

Resorcerer

Expensive, but popular, as it can be used for visual editing of many more types of data than ResEdit.

HexEdit

A binary editor, which in fact is normally used more for editing the data fork rather than the resource fork.

ResKnife

Open-source editor for Mac OS X; no longer maintained.

Rezycle

A macOS tool that extracts resources from a resource fork into separate binary files while converting many types into formats suitable for modern development.

resource_dasm

An open-source resource extractor for macOS and Linux, also capable of converting many resources into modern formats.

ResForge

resource editor for macOS, capable of editing classic resource fork files and related formats. Compatible with macOS 10.14 or later. Runs natively on both 64-bit Intel and Apple Silicon.

Compatibility

The complexity of programming with resource forks has led to compatibility problems when accessing other file systems via file sharing protocols such as AFP, SMB, NFS and FTP, when storing to non-HFS volumes, or when transmitting files to other systems in other ways (such as via email). The AFP protocol natively supports Resource Forks, and so resource forks are typically transmitted to these volumes as-is, and stored by the server transparently to clients. The SMB protocol supports a file metadata system similar to Macintosh forks known as Alternate Data Streams (ADSes hereafter). macOS did not support storing resource forks in ADSes on SMB volumes by default until Mac OS X v10.6. In previous versions of the OS, including upgraded versions of 10.6, this feature can be enabled with a param change or by creating a special file.

Networked file sharing protocols such as NFSv3 and FTP do not have a concept of file metadata, and so there is no way to natively store resource forks. This is also true when writing to certain types of local file systems, including UFS, and on SMB volumes where Alternate Data Stream support is not enabled. In those cases, macOS stores metadata and resource forks using a technique called AppleDouble, in which the data fork is written as one file, and the resource fork and metadata are written as an entirely separate file preceded by a "._" naming convention. For example: ExampleFile.psd would contain the data fork, and ._ExampleFile.psd would contain the resource fork and metadata.

Compatibility problems can arise because macOS will handle storage of resource forks differently, depending on macOS version, settings, and file system type. For example, on an SMB network with a mixture of 10.5 and 10.6 clients. A freshly installed 10.6 client will look for and store resource forks on an SMB volume in ADSes, but the 10.5 client will (by default) ignore ADSes and use AppleDouble format to handle forks. If a fileserver supports both AFP and NFS, then clients using NFS will store files in AppleDouble format, whereas AFP users will stored the resource fork natively. In those cases, compatibility can sometimes be maintained by forcing clients to use, or not use, AppleDouble format.

Many fileservers providing AFP support do not natively support resource forks on their local file systems. In those cases the forks may be stored in special ways, such as specially named files, special directories, or even Alternate Data Streams.

Another challenge is preserving resource forks when transmitting files using non-resource fork-aware applications or with certain transfer methods, including email and FTP. A number of file formats, such as MacBinary and BinHex, have been created to handle this. Command-line system tools SplitForks and FixupResourceForks allow manual flattening and merging of resource forks. In addition, a file server seeking to present file systems to Macintosh clients must accommodate the resource fork as well as the data fork of files; UNIX servers providing AFP support usually implement this with hidden directories.

Carbon applications compiled for the Intel architecture may have byte order issues when working with resources, because most resource data is stored in big-endian byte order, as used by the 68000 and PowerPC architectures, which does not match the Intel architecture's little-endian byte order. While the operating system automatically handles these byte order differences for the overall resource fork format and for standard resource types like 'snd ' or 'moov', any resources with non-standard types must have their data byte-swapped manually to ensure consistent behavior regardless of architecture.

Until the advent of Mac OS X v10.4, the standard UNIX command-line utilities in macOS (such as cp and mv) did not respect resource forks. To copy files with resource forks, one had to use ditto or CpMac and MvMac.

Other operating systems

The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the Xerox Alto in Smalltalk-76. The concept is now largely universal in all modern operating systems. However, the concept of the resource fork remains peculiar to the Macintosh. Most operating systems used a binary file containing resources, which is then "tacked onto" the end of an existing program file. This solution is used for Windows resources for instance, and similar solutions are used with the X Window System, although the resources are often left as a separate file.

The Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support is called an alternate data stream. Windows operating system features (such as the standard Summary tab in the Properties page for non-Office files) and Windows applications use them and Microsoft was developing a next-generation file system that has this sort of feature as basis.

Early versions of the BeOS implemented a database within the file system, which could be used in a manner analogous to a resource fork. Performance issues led to a change in later releases to a system of complex file system attributes. Under this system resources were handled in a fashion somewhat more analogous to the Mac.

AmigaOS does not use forked files. Its executable files are internally divided into a modular structure of large pieces (hunk) capable of storing code, data, and additional information. Similarly, data and project files have a chunk structure codified in the IFF standard. Other file types are stored similarly to other operating systems. Though not strictly a resource fork, AmigaOS stores meta data in files known as .info files. .info files can be identified by the .info extension; for example, if you save a project to a disk, two files will be saved, MyProject and MyProject.info. MyProject would be the actual project data and MyProject.info would contain the project icon, information regarding which program is needed to open the project (since there is no application binding in AmigaOS), special project options and any user comments. .info files are invisible on the Amiga's desktop (Workbench). The icon on the desktop, taken from the .info itself, is the interface metaphor through which the user interacts both with the project itself and its associated .info file. A dialog box accessible by right-clicking the icon allows the user to see and modify the metadata present in the .info file. .info files can be seen as individual files in the command-line interface or a File manager. Modern AmigaOS clones (AROS, MorphOS and AOS4) inherit the structure (complete with metadata) of the .info files of older AmigaOS versions, and can also accept standard PNG graphic files as icon bitmaps in their .info files.

NeXT operating systems NeXTSTEP and OPENSTEP, their successor, macOS, and other systems like RISC OS implemented another solution. Under these systems the resources are left in an original format, for instance, pictures are included as complete TIFF files instead of being encoded into some sort of container. These resources are then placed in a directory along with the executable code and "raw data". The directory (called a "bundle" or "application directory") is then presented to the user as the application itself. This solution provides all of the same functionality as the resource fork, but allows the resources to be easily manipulated by any application – a "resource editor" (like ResEdit) is not needed. From the command-line interface, the bundle appears to be a normal directory. This approach was not an option on the classic Mac OS, since the file system (MFS) did not support separate catalog directories. When catalog file support was included in Mac OS, with the HFS filesystem, the resource fork was retained. macOS does retain the classic Resource Manager API as part of its Carbon libraries for backward compatibility. However, the resources themselves can now be stored in separate data files within the file system – the Resource Manager now hides this implementation change from the client code.

See also

• Fork (file system)

External links

• Description of the Resource File Format
• Apple Developer Documentation Archive: Resource Manager Reference
• Apple Developer Documentation Archive: Bundle Programming Guide
• Rezycle – Resource extraction tool
• Mac OS X Services – A Mac OS X Service to delete the resource fork of a file through context menu
• What's up with Mac OS X Resource forks, Extended Attributes, NTFS Streams and Dot-Underscore files?
• When I save a file using SMB protocol, what information is saved in the "dot-underscore" (._) files? How is this information stored on an NTFS file system?