Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Resource fork
View on Wikipedia | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
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.
In a 1986 technical note, Apple strongly recommended that developers do not put general data into the resource fork of a file. According to Apple, there are parts of the system software that rely on resource forks having only valid Resource Manager information in them.[1]
The resource fork was conceived and implemented by Apple programmer Bruce Horn.
Macintosh file systems
[edit]The resource fork has three purposes in classic Macintosh file systems:
- It stores all graphical data on disk until it is needed, then retrieved, drawn on the screen, and thrown away. This software variant of virtual memory reduces memory requirements from 1 MB in the Lisa to 128 KB in Macintosh.[citation needed]
- It provides a way for a non-programmer to perform internationalization and localization, because all the pictures and text are stored separately in a resource fork.
- It can be used to distribute nearly all of the components of an application in a single file, reducing clutter and simplifying application installation and removal.
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. (Microsoft Windows also has a concept of "resources", but these are completely unrelated to resources in Mac OS.)
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.[2]
As of August 7, 2002, Apple recommended that developers should not build resources into resource forks in Mach-O binaries on Mac OS X.[3]
Resource identifiers
[edit]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
[edit]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[citation needed]. 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.
In macOS, forks are named file/..namedfork/forkname, e.g., the resource fork of the file IMG_0593.jpg is IMG_0593.jpg/..namedfork/rsrc. The ls command supports a -l@ option which lists a file's forks.
Accessing
[edit]Resource forks appear as the extended attribute com.apple.ResourceFork.[4]
Previously resource forks were accessed via the 'Resource Manager' API. This API is now deprecated.[5]
Under the deprecated API:
- 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.
- 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.
- 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.
- 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.[6]
Data types
[edit]The smallest elements making up a resource fork are called data types. There are several data types. After a resource fork is accessed, its contents can be found by reading it in as appropriate for the data types defined in advance. Placing definitions inside the program stating how data is to be treated makes it possible to store resources called TMPL resources as well. Using this method increases the visibility of the data when viewed with a program such as ResEdit, making later editing simpler. As the Macintosh platform originated with Motorola-based processors (68k and PPC), the data is serialized to disk in big-endian format.
The following is a list of the major data types, in alphabetical order.
| Data type | actual name | Description |
|---|---|---|
| BBIT | binary bit | Represents a single Boolean bit (true or false). Normally the number of BBITs must be a multiple of 8. |
| BOOL | Boolean | Represents a Boolean value. It consists of 2 bytes; 256 is true, and 0 is false. |
| CHAR | character | Represents a one-byte character. |
| CSTR | C string | Represents a string of the form used in the C programming language: a null-terminated string of bytes. |
| DLNG | decimal long word integer | A decimal long word (4 byte integer). Represents values between approximately − 2.1 billion and 2.1 billion. |
| HEXD | hex dump | Indicates that the data from this position to the end is hexadecimal. This is used to represent code resources or compressed data. |
| HLNG | long word hexadecimal | This data is treated as a 4 byte hexadecimal value. It is used, among other things, to represent integers greater than 2.1 billion, such as unsigned long values in C. |
| PSTR | Pascal string | Represents a Pascal string, with the first byte giving the length of the string. |
| TNAM | type name | A string representing a value such as a creator code, which is always 4 bytes long. |
| RECT | rectangle | Represents the coordinates of the corners of a rectangle (top, left, bottom, right). Always 8 bytes long. |
Types
[edit]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 | Defines the format for the resource data |
| 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
[edit]- 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.[7]
- 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.[8]
Compatibility
[edit]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.[9]
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.
Older applications written with the Carbon API have a potential issue when being ported to the current Intel Macs. While the Resource Manager and operating system know how to deserialize data correctly for common resources like 'snd ' or 'moov', resources created using TMPL resources have to be byte swapped manually to ensure file interoperability between PPC and Intel-based versions of an application. (While the resource map and other implementation details are big-endian, the Resource Manager by itself does not have any knowledge of the contents of a generic resource, and so cannot perform the byte swapping automatically.)
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
[edit]The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the Xerox Alto in Smalltalk-76.[10] 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 on Microsoft Windows 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
[edit]References
[edit]- ^ "Technical Note FL19: Data in Resource Fork: Don't do It". Apple Developer. Mar 1, 1986. Archived from the original on Aug 16, 2023.
- ^ "Technical Note TN1150: HFS Plus Volume Format". Apple Developer. Mar 5, 2004. Retrieved 11 February 2024.
- ^ "Technical Q&A QA1175: Resource forks in Mach-O binaries". Apple Developer. Aug 7, 2002. Archived from the original on Aug 16, 2023.
- ^ Stacey, Jon (August 21, 2009). "Mac OS X Resource Forks". Jon's View. Retrieved 2012-10-22.
- ^ "Resource Manager Reference". Apple Developer. Archived from the original on Oct 25, 2012. Retrieved 2012-10-22.
- ^ "Using Pathnames". Apple Developer. March 31, 2001. Archived from the original on 2002-12-18. Retrieved 2002-12-18.
- ^ fuzziqersoftware. "resource_dasm". GitHub.
- ^ andrews05. "ResForge". GitHub.
- ^ "Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear". Apple Support. Archived from the original on Jul 24, 2010. Retrieved 2010-04-19.
- ^ "The Early History of Smalltalk". Archived from the original on 2008-07-10. Retrieved 2008-07-24.
External links
[edit]- Description of the Resource File Format
- Apple Developer Resource Library: Resource Manager Reference
- Apple Developer Resource Library: Resource Management, Bundles
- The Grand Unified Model – History of the resource fork, from folklore.org
- 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?
Resource fork
View on GrokipediaINODE_HAS_RSRC_FORK (indicating presence) and INODE_NO_RSRC_FORK (indicating absence), allowing legacy applications and files to function without modification.[4] However, APFS de-emphasizes native fork support in favor of extended attributes (xattrs), which store equivalent metadata—like Finder information via the com.apple.FinderInfo attribute—in a more efficient, attribute-based model integrated into the file's inode structure.[4] Many Carbon APIs for direct resource fork manipulation, such as FSGetResourceForkName and FSCreateFork, were deprecated starting in macOS 10.8 (Mountain Lion), signaling a shift away from resource forks in new development.[5][6] Furthermore, since macOS 10.12, code signing for app bundles prohibits resource forks or related extended attributes to prevent security risks from hidden data, enforcing their removal during builds.[7] Despite this evolution, resource forks persist in macOS for compatibility with older files, particularly in cross-platform scenarios where AppleDouble encoding preserves them as sidecar files on non-fork-supporting systems like FAT32 or NTFS.[8]
Overview and History
Definition and Purpose
A resource fork is a distinct component of a file in Macintosh file systems, serving as one of two primary forks alongside the data fork. The data fork contains the primary, unstructured content of the file, such as the text of a document or the executable code of an application. In contrast, the resource fork stores supplementary, structured data elements, including icons, menus, dialog layouts, and other metadata that enhance the file's functionality without altering its core content.[9][10] The primary purpose of the resource fork is to enable modular file management by separating descriptive and executable resources from the main data, allowing them to be shared across files, edited independently, or loaded dynamically at runtime. This design facilitates efficient resource handling, such as updating user interface elements or localizing strings without recompiling the entire application, and supports the system's ability to manage complex, graphical applications.[10][2] For example, in a Macintosh application, the resource fork might contain code segments identified as 'CODE' resources, string tables in 'STR#' format for user-facing text, and bitmaps via 'PICT' resources, all organized in a hierarchical structure with a resource map for quick access. This approach originated to support the graphical user interfaces of early Macintosh systems, introduced in 1984 with the Macintosh File System (MFS).[10][11]Historical Development
The resource fork was introduced with System 1 in 1984, designed by Apple for the original Macintosh 128K to efficiently store and manage graphical user interface (GUI) elements such as icons, menus, windows, dialogs, fonts, and controls, separate from the file's primary data fork.[12] This dual-fork structure, part of the Macintosh File System (MFS), enabled modularity, dynamic loading, and easy customization of resources without altering application code, supporting the event-driven GUI in a system limited to 128K RAM and 64K ROM.[12] The Resource Manager, a core component of the Macintosh Toolbox, was created to handle these resources, providing APIs likeGetResource and AddResource for reading, writing, and searching resource files, initialized at system startup with the system resource file.[12]
Resource forks evolved as an integral part of the Hierarchical File System (HFS), introduced in 1986 with the Macintosh Plus and System 3.0 to support nested directories and larger storage devices like the Hard Disk 20.[13] HFS retained the dual-fork model, tracking resource forks in catalog tree records with separate logical and physical end-of-file fields (e.g., ioFlRLgLen for resource fork length), enhancing scalability for volumes up to 2 GB and thousands of files while maintaining compatibility with earlier flat-file systems via working directory reference numbers.[13] Through Mac OS 9, resource forks remained central, with enhancements in System 7 (1991) improving management via 32-bit addressing for larger resources, virtual memory support, and resources like 'size' for specifying application memory needs, alongside AppleShare for permissions on shared resources.[14]
A key milestone occurred during the PowerPC transition in 1994, which impacted resource formats by shifting executable code from traditional 'CODE' resources in the resource fork to the data fork using the Preferred Executable Format (PEF), while introducing 'cfrg' resources in the resource fork to indicate PowerPC code location and architecture.[15] This change, managed by the new Code Fragment Manager and Mixed Mode Manager for cross-architecture compatibility, allowed fat binaries to support both 68k and PowerPC code, with resource forks handling metadata like routine descriptors for executable resources (e.g., 'MDEF', 'LDEF'), ensuring backward compatibility through emulation.[15]
Resource forks were marked as legacy in Mac OS X (2001), with full backward support but no new development encouraged, favoring bundles and property lists (XML-based) for storing application resources and metadata to align with Unix conventions.[16] Apple recommended migrating to bundles, which package resources as directories with property list files (e.g., Info.plist), avoiding fork-related issues in cross-platform transfers.[16] Phase-out intensified in macOS 10.7 Lion (2011), removing direct access paths like filename/rsrc and urging conversion to extended attributes or bundles, though APIs like FSRef and FSOpenResourceFile persisted for legacy compatibility.[17] Post-2011, support continued for legacy applications, with tools like xattr for managing resource forks as extended attributes (com.apple.ResourceFork). In macOS Sonoma (2023) and subsequent versions including those as of November 2025, resource forks remain supported natively via extended attributes for backward compatibility and archival access, though not encouraged for new development.[18][19]
File System Implementation
Structure in HFS and HFS+
In the Hierarchical File System (HFS), introduced in 1986, the resource fork functions as a distinct data stream parallel to the data fork within each file, enabling the storage of structured metadata such as icons, menus, and code segments. The file system's catalog, organized as a B-tree, indexes the locations and extents of both forks for efficient access, while the extents file, also a B-tree, manages overflow allocations beyond initial blocks. Within the resource fork itself, data is structured starting with a 16-byte header that specifies the offset and length of the data blocks (typically beginning at offset 256) and the resource map; this header includes fields for the data blocks offset (4 bytes), resource map offset (4 bytes), data blocks length (4 bytes), and resource map length (4 bytes). The resource map follows, containing a type list enumerating resource types with counts and offsets to reference lists, a name list for resource names, and a reference list mapping resource IDs to their attributes, names, and data block offsets; resources are stored as variable-length entries in the data blocks section, referenced by 3-byte offsets from the header's data start, allowing flexible sizing without fixed positions.[20][10] HFS+ , released in 1998, retained the core duality of data and resource forks while introducing significant enhancements for scalability and reliability, including optional journaling to protect against corruption from unexpected shutdowns, support for file sizes up to 8 exabytes (2^63 bytes), and Unicode (UTF-16) filenames up to 255 characters. The catalog file in HFS+ remains a B-tree but uses larger nodes (up to 32 KB) and 32-bit keys for improved performance; fork metadata is now encapsulated in an HFSPlusForkData structure within catalog records, comprising a 64-bit logical size, 32-bit clump size (allocation unit), 32-bit total blocks, and an array of eight 8-byte extent descriptors (each with 4-byte start block and 4-byte block count) for initial allocations, with additional extents stored in a separate B-tree-based extents overflow file using forkType 0xFF to denote resource forks. This design ensures backward compatibility with HFS while accommodating larger volumes and faster access.[2] Resources within the HFS+ resource fork maintain the variable-length entry format from HFS, with offsets in the resource map pointing to data blocks that include a 4-byte length prefix followed by the resource content, allowing dynamic growth without reorganizing the entire fork. In 64-bit contexts, HFS+ handles resource forks seamlessly through the UInt64 logicalSize field in HFSPlusForkData, supporting terabyte-scale resources without truncation, though applications must use 64-bit APIs like FSRef for full compatibility to avoid legacy 32-bit limitations. A common pitfall arises during disk repairs with tools like fsck_hfs, where inconsistencies in the extents B-tree or non-journaled volumes can lead to resource fork corruption or orphaning, potentially requiring manual reconstruction from backups.[2]Transition to APFS and Modern macOS
The Apple File System (APFS) was introduced in 2017 with macOS High Sierra as the successor to HFS+, becoming the default file system for all Apple platforms including macOS, iOS, and tvOS. APFS adopts a single-stream file model, eliminating native multi-fork support like the resource fork of HFS+; instead, legacy resource data is preserved through extended attributes (xattrs), particularly the "com.apple.ResourceFork" attribute, which stores the binary contents of classic resource forks. For structured data such as application resources, APFS encourages migration to package bundles, where files are organized in directories rather than forks, ensuring compatibility across SSD-optimized storage and encryption features.[4][21] During the transition, developers shifted from classic tools like ResEdit, which directly edited resource forks in HFS files, to modern integrated development environments such as Xcode, which manages resources within .app bundle structures for easier localization and maintenance. For handling legacy files on APFS volumes, thexattr command-line utility—available since early macOS versions—allows extraction and manipulation of resource fork data stored as extended attributes, enabling scripts to copy or convert forks without data loss. This approach supports gradual migration while avoiding direct fork dependencies in new code.[22]
In macOS Sequoia (2024) and later versions, resource forks remain emulated via compatibility layers in APFS, primarily through the "com.apple.ResourceFork" extended attribute, to maintain backward compatibility for older files and applications. Apple documentation advises against creating new resource forks, favoring extended attributes or package bundles for metadata and resources to align with APFS's single-stream design and iOS/macOS convergence, where iOS lacks fork support entirely and relies on unified bundle formats for cross-platform consistency. Updates in APFS format versions through 2024, including improved extended attribute handling in macOS Sonoma and Sequoia, further de-emphasize forks without removing legacy emulation.[23][24]
Resources and Organization
Resource Types and Identifiers
In the resource fork system of classic Mac OS, resources are classified using a type-ID scheme, where each resource is identified by a four-character ASCII type code and a unique 16-bit signed integer ID.[25] The type code, known as an OSType, categorizes the resource's purpose, such as'MENU' for menu definitions or 'PICT' for picture data.[26] The ID, ranging from -32768 to 32767, ensures uniqueness within its type across the resource file, allowing up to 65,536 possible resources per type.[25]
Resources are organized hierarchically within the resource fork's map, first grouped by type and then sorted by ID for efficient lookup by the Resource Manager.[25] Each resource entry includes an 8-bit attributes field that controls behaviors like preloading into memory on file open (bit 7 set), marking as purgeable for memory management (bit 6 set), or protecting against modification (bit 5 set).[25] This structure supports modular organization, enabling applications to load only necessary components dynamically.
Common examples include 'CODE' resources for executable code segments and 'STR#' for lists of Pascal strings used in localization.[25] Following the transition from Mac OS 9 to macOS, the Carbon API supporting resource forks—including many classic types—was deprecated in macOS 10.8, with resources increasingly replaced by structured files in application bundles, such as JSON-formatted property lists for metadata.[27]
Common Data Formats
Resource forks in the classic Macintosh operating system stored various types of data in binary formats tailored to specific resource types, enabling efficient access by the system's managers such as the Icon Utilities, Window Manager, and Menu Manager. For instance, the 'ICN#' resource type, used for black-and-white icons displayed by the Finder, consists of a fixed-size binary structure comprising 128 bytes of bitmap data representing a 32×32 pixel icon followed by another 128 bytes for the corresponding mask, where each bit corresponds to a pixel and defines the icon's shape against the background.[28] Similarly, the 'WIND' resource type defines window templates with a binary layout starting with a 16-byte initial rectangle (four 4-byte integers for top, left, bottom, and right global coordinates), followed by a 2-byte window definition ID (specifying the procedure and variation, such as 0 for a plain document window), flags for visibility and close box presence (2 bytes each), a 4-byte reference constant, a Pascal string for the title (1-byte length plus up to 255 characters), and an optional 2-byte positioning specifier, concluding with a list of control resource IDs if applicable.[29] Structured data formats within resources often employed compact, self-describing binary representations to minimize storage while supporting dynamic interpretation. The 'STR ' resource type holds simple text as a Pascal string, beginning with a single byte indicating the length (0–255) followed directly by that number of character bytes, facilitating quick loading for labels, prompts, or identifiers without null termination.[30] More complex hierarchies appear in the 'MENU' resource type, which begins with a 2-byte menu ID, reserved placeholders for dimensions (4 bytes each), a 2-byte procedure ID (typically 0 for standard menus), a 4-byte enabled state flag (bit 0 for menu enablement, higher bits for up to 31 items), a 1-byte title length followed by the title characters, and then a variable-length sequence of per-item records—each including 1-byte text length and text, 2-byte icon or equivalent specifier, 1-byte marking character or submenu ID, and 1-byte style flags (e.g., bold or italic)—terminated by a 1-byte zero marker.[31] Graphics resources heavily relied on QuickDraw's raster-based formats from the Macintosh's introduction in 1984 through the 2000s, where elements like patterns, pictures ('PICT' resources as sequences of drawing opcodes), and cursors used bitmaps or command streams for rendering lines, shapes, and fills at 72 dpi resolution.[32] Audio data in 'snd ' resources followed a modular binary header format, with common format 1 starting with a 2-byte type (1), 2-byte data count (often 1), 4-byte data type (e.g., 3 for sampled sound), 4-byte initialization options (e.g., 0x80 for mono), 2-byte command count, followed by 8-byte commands (with high-bit offsets to data), and appended sound data such as a 24-byte header plus samples.[33] Font resources, particularly 'FONT' for bitmap fonts, encoded glyph metrics and bitmaps in a structured binary table beginning with 2-byte font type, 1-byte first/last character codes (0–255), offsets to width and location tables (2 bytes each), 2-byte font rectangle dimensions, 1-byte font interlock, 1-byte tracking offset, 2-byte ascent/descent/leading, 2-byte widths table length, and variable glyph bitmaps scaled to point sizes like 9 or 12 pt.[34] With the shift to Mac OS X in 2001, resource fork usage declined as QuickDraw's formats were supplanted by Core Graphics (Quartz 2D), which adopted PDF-based vector rendering for higher fidelity and scalability, though legacy resource formats remained supported for compatibility via the Carbon framework and Core Foundation data types like CFData for structured content.[35]Editing and Access
Resource Editing Tools
ResEdit, introduced by Apple in 1984 as a core developer tool for the Macintosh, provided a graphical interface for creating and editing resources directly within a file's resource fork.[36] It supported specialized editors for common resource types, such as the 'ICN#' editor for black-and-white icons, which allowed users to draw and modify pixel-based graphics using tools like pencils, brushes, and flip/rotate functions, and the 'MENU' editor for adjusting menu structures, including item text, keyboard shortcuts, and hierarchical submenus.[37] A typical workflow involved opening an application file in ResEdit, navigating to the 'ICN#' resource type, selecting or creating an icon resource with a unique ID, and editing its bitmap data visually before saving changes back to the resource fork—enabling developers to customize application icons without recompiling code. The tool remained in active use through the 1990s, with its final major version (2.1.3) released in 1994, though it saw limited support until around 1998.[38] As a third-party alternative, Resorcerer, developed by Mathemaesthetics starting in the late 1980s and continuing through the 2000s, offered more advanced capabilities for resource management on classic Mac OS.[39] It extended beyond ResEdit's graphical focus by including a comprehensive hexadecimal viewer and editor, allowing direct manipulation of raw resource data for types without built-in editors, such as binary structures or custom formats, while supporting over 100 resource types with specialized tools for icons, menus, and even PowerPC disassembly. Resorcerer received acclaim in developer communities, winning awards like the 1993 Eddy Award for Best New Developer Tool, and its final major release (version 2.4.1) occurred in 2001, with compatibility updates for Mac OS X.[39] For batch operations, users could script resource modifications using its template system to apply changes across multiple files, such as updating menu resources in a suite of applications. In modern macOS environments, resource editing has shifted toward bundled resources rather than traditional forks, with Xcode's Interface Builder serving as the primary graphical tool for managing user interface elements like storyboards and XIB files, which compile into application bundles containing resource-like assets such as images and property lists.[40] For direct resource fork manipulation, Apple provides command-line utilities DeRez and Rez, which translate binary resources to human-readable text files (.r format) and vice versa; DeRez decompiles a resource fork into Rez-compatible statements for editing in a text editor, while Rez recompiles them back, facilitating scripted workflows like automating icon additions across files via shell scripts.[41][42] These tools, introduced with Macintosh Programmer's Workshop (MPW) in 1986, remain available but deprecated since Xcode 6 in 2014, issuing warnings on macOS to encourage migration to bundle-based systems.[43] Open-source alternatives like ResForge, a cross-platform editor forked from ResKnife and actively maintained as of 2024, enable viewing and modifying classic resource forks on contemporary macOS without deprecation issues, supporting hex editing and resource extraction for legacy files.[44] It addresses gaps in Apple's tools by providing a native GUI for formats like icons and menus, often used in preservation efforts for pre-OS X software.Programmatic Access Methods
The Resource Manager API, part of the classic Macintosh Toolbox, provides the primary programmatic interface for accessing resource forks in early macOS versions based on HFS and HFS+. This API uses handle-based memory management, where resources are loaded into relocatable blocks managed by the Memory Manager. Key functions includeGetResource, which retrieves a resource by its type (a four-character OSType) and ID, returning a handle to the loaded data or NIL if not found; it searches open resource files starting from the current one and automatically loads the resource if necessary.[10] Another essential function is AddResource, which adds a handle containing resource data to the current resource file, specifying the type, ID, and optional name; the resource remains in memory until written to disk via UpdateResFile or WriteResource.[10] These functions require opening the resource fork first, typically with OpenResFile or its FSSpec variant FSpOpenResFile, which returns a reference number for subsequent operations.[10]
To enumerate resources, developers use CountTypes to obtain the number of unique resource types in the current fork, followed by iterative calls to Get1IndType to retrieve each type by index (1-based). This handle-based approach allows efficient manipulation but requires careful memory management, such as detaching handles with DetachResource before modification to avoid relocation issues. The following C code snippet illustrates opening a resource fork and enumerating its types:
#include <Resources.h>
#include <Files.h>
OSErr OpenAndEnumerateTypes(FSSpec *spec) {
short refNum;
OSErr err = FSpOpenResFile(spec, fsRdPerm, &refNum);
if (err != noErr) return err;
UseResFile(refNum); // Set as current [fork](/page/Fork)
short numTypes = CountTypes();
ResType theType;
for (short i = 1; i <= numTypes; i++) {
GetIndType(&theType, i);
// Process theType (e.g., log or load resources of this type)
}
CloseResFile(refNum);
return noErr;
}
#include <Resources.h>
#include <Files.h>
OSErr OpenAndEnumerateTypes(FSSpec *spec) {
short refNum;
OSErr err = FSpOpenResFile(spec, fsRdPerm, &refNum);
if (err != noErr) return err;
UseResFile(refNum); // Set as current [fork](/page/Fork)
short numTypes = CountTypes();
ResType theType;
for (short i = 1; i <= numTypes; i++) {
GetIndType(&theType, i);
// Process theType (e.g., log or load resources of this type)
}
CloseResFile(refNum);
return noErr;
}
ResError is recommended after Resource Manager calls.[10]
In the Carbon framework, which bridges classic APIs to modern macOS, resource fork access is facilitated through FSRef-based functions like FSOpenResourceFile. This function opens a file's resource fork using an FSRef pointer, a fork name (typically the Unicode string for the resource fork), and permissions, returning a ResFileRefNum for use with legacy Resource Manager calls. For instance, FSGetResourceForkName retrieves the standard Unicode name for the resource fork, enabling explicit fork targeting in HFS/HFS+ volumes.[45] Carbon emulates resource forks on APFS via extended attributes, but direct manipulation often relies on low-level syscalls like getxattr and setxattr from <sys/xattr.h>. The resource fork data is stored as the extended attribute named "com.apple.ResourceFork", allowing retrieval of its contents as binary data; for example, getxattr(path, "com.apple.ResourceFork", buffer, size, 0, 0) fetches the attribute value, where the position parameter is used for seeking within large resource data.[46] Writing requires setxattr with similar parameters, though macOS imposes size limits and security checks on extended attributes to prevent abuse.[46]
For application bundles in modern macOS, Core Foundation's CFBundle API provides a higher-level abstraction for accessing bundled resources, which have largely replaced traditional resource forks since the shift to flat directory structures in bundles. CFBundleGetMainBundle returns a CFBundleRef for the app's main bundle, from which functions like CFBundleGetDataPointerForName load named resources (e.g., images or strings) directly into memory, handling localization and versioning automatically.[47] This API integrates with Objective-C via NSBundle and Swift via Bundle, as shown in the following Swift example for loading a bundled resource:
import Foundation
let bundle = Bundle.main
if let url = bundle.url(forResource: "example", withExtension: "png"),
let data = try? Data(contentsOf: url) {
// Process data (e.g., load image)
}
import Foundation
let bundle = Bundle.main
if let url = bundle.url(forResource: "example", withExtension: "png"),
let data = try? Data(contentsOf: url) {
// Process data (e.g., load image)
}
[NSBundle mainBundle] URLForResource:withExtension:. Post-2014 developments in Swift emphasize safe, type-checked resource loading without direct fork manipulation, aligning with APFS's extended attribute emulation for compatibility.
Compatibility and Extensions
Backward Compatibility in macOS
Modern macOS maintains backward compatibility for resource forks primarily through the Apple File System (APFS), which maps legacy resource fork data to extended attributes for seamless access by older applications. In APFS, resource forks are stored as the extended attribute named "com.apple.ResourceFork," allowing Intel-based applications running under emulation to interact with them transparently without modification.[23] This mapping preserves the structure and functionality of resource forks from HFS and HFS+ volumes during file system migrations, ensuring that legacy files retain their metadata.[48] Rosetta 2, introduced in 2020 with macOS Big Sur, further supports backward compatibility by emulating x86-64 Intel applications on Apple silicon Macs.[49] These emulated applications access resource forks via the same APFS extended attribute mechanism, maintaining compatibility for legacy software without requiring developers to update code for native ARM architecture. However, this emulation layer does not alter the underlying file system handling, relying on APFS's native support to avoid disruptions in resource fork operations. Despite these mechanisms, limitations exist in modern macOS environments. Sandboxed applications, mandatory for App Store distribution since macOS 10.7, face restrictions on writing new resource forks due to confined file system access entitlements, often resulting in errors or fallback to data fork storage. For instance, attempts to modify resource forks in sandboxed contexts can trigger violations, as seen in cases where font files with resource fork data are inaccessible.[50] To address compatibility challenges, macOS provides tools like theditto command-line utility, which preserves resource forks and HFS metadata during file copies and archiving.[51] By default since macOS 10.4, ditto uses the --rsrc option to store resource data in AppleDouble format (e.g., ._ files) on non-native file systems, ensuring portability for legacy files.[51] Additionally, as of 2025, security analyses highlight risks of abusing the com.apple.ResourceFork extended attribute to hide malicious code, such as shellcode, underscoring the need for caution in legacy file handling.[52]
Implementations in Other Systems
In Unix-like systems such as Linux, resource forks from Macintosh Hierarchical File System (HFS+) volumes can be accessed through specialized tools and filesystem drivers, providing partial emulation for compatibility with macOS files. The Darling project, a macOS compatibility layer for Linux initiated in the 2010s, includes a FUSE-based module (darling-dmg) that mounts HFS+ disk images and exposes resource forks either as extended attributes (xattrs) or via the named fork path/original/filename#..namedfork#rsrc, enabling read-only access to these structures within emulated environments.[53] Earlier efforts like Darwine, a 2000s project for running macOS binaries on Linux, offered limited support for HFS+ features including resource forks through userspace emulation, though it was less mature and focused on Darwin kernel compatibility. Additionally, Linux kernel modules such as hfsplus provide basic read-write support for HFS+ filesystems, but resource forks require supplementary utilities like hfsprogs or the hfsfuse FUSE driver for full extraction and manipulation, as native kernel handling treats them as secondary streams without automatic preservation during copies.[54][55]
On Windows, the concept of resource forks finds a partial analog in the Resource Compiler (rc.exe), integrated into Visual Studio, which compiles declarative resource scripts (.rc files) into binary resource files (.res) that are linked into executable binaries (.exe or .dll), embedding elements like icons, menus, and dialogs in a structured format reminiscent of Mac resources.[56] Third-party tools such as Resource Hacker extend this by allowing users to view, edit, add, or extract these embedded resources from Windows executables, facilitating manipulation similar to classic Mac resource editors.[57] More broadly, the NTFS filesystem supports alternate data streams (ADS), which attach named secondary data sequences to files (e.g., filename:streamname:$DATA), serving as a flexible mechanism for storing ancillary metadata or resources without altering the primary data stream, much like a resource fork.[58]
Cross-platform implementations draw from BeOS and its derivatives, where the Be File System (BFS), introduced in the late 1990s, incorporated file attributes as typed metadata streams attachable to files, enabling database-like queries and storage of structured data analogous to resource forks for applications like media indexing.[59] Zeta, a commercial BeOS successor developed in the early 2000s, retained BFS with its attribute system, supporting similar stream-based extensions for file resources in a multithreaded environment. In contemporary systems, extended attributes provide a widespread analog: ext4 on Linux allows user-defined name-value pairs (up to 64 KiB per attribute) in four namespaces (user, system, security, trusted), suitable for embedding resource-like data directly in inodes or extended blocks.[60] Similarly, NTFS ADS offer unlimited named streams per file, with independent sizing and attributes, used for purposes ranging from security metadata to application-specific extensions.[58]