Macintosh File Forks

• Home
• MacDisk
• MacImage
• Download
• Support
• FAQs
• Site Map

• Home
• MacDisk
• MacImage
• Download
• Support
• FAQs
• Site Map

File Forks

Under the Macintosh file system (called HFS, for Hierarchical File System, the current 32-bit version being called HFS+ or MacOS Extended), files are not monolithic and do not consist of one single segment. They may be composed of two pieces, called forks, i.e. a data fork and a resource fork. Only one of the two forks may be empty.
The creators of the Macintosh file system chose to put apart what is stored in a single data stream on most computers. Please note that NTFS also features file streams.

Data Fork

The data fork contains what we generally call a file on the PC, that is the text created by a word processor, the pixels building a picture, etc. When transferring data files between Macintosh and PC, the data fork is generally the only part of interest (the major exception being font files and programs [executable files], see below).

Resource Fork

The resource fork may contain the code of a program, the commands of a font file, etc. Some programs store a preview picture in the resource fork.
The code of programs is stored in the resource fork. Program files often have an empty data fork.
This explains why it can happen that a program, transferred through channels ignoring file forks and having lost its resource fork, can no longer be executed (error -39, meaning unexpected end of file).
Against what is often said, even by knowledgeable persons, the resource fork doesn't contain the signature of Macintosh files (file type and file creator), which is stored in the disk catalog.

Why a Resource Fork?

The resource fork is organised as a data base, which allows for a fast access to all components of the stream. This is a big advantage for some applications. It is also possible to change and replace some elements without disturbing the rest of the fork.

The Dreaded "Lost Fork" Syndrom

The "lost of the resource fork" is a mythical catastrophe about which many messages are exchanged on all forums handling Macintosh file transfers. One should try to remain sober. The resource fork is not everything. Most of the time, the problem is not a fork problem, but a signature problem.
When a Macintosh data file is not recognized any more, for an example after a transfer through another file system, it remains usable, most of the time. If it is not double-clickable any more, the explanation lies in the lost of the Finder information (signature, and so on). In this case, just launch the application which can handle such files and open the file with File | Open.
In the case of programs (applications), things are worse. The classical error message is error -39 (unexpected end of file). This happens because the Finder tries to open the resource fork to launch the program and finds that it is empty.
In this case, it is of no use to try to apply a "better" signature to the truncated file. One should redo the transfer using correct media, correct tools and correct procedures. See Installation procedures given for several situations.

How to Keep Both Forks Together?

Two main methods are commonly used to keep together both forks of Macintosh files on communication lines and on servers which don't know anything about forks: the MacBinary standard and the BinHex standard.
Apple has also published two specifications, Apple Single to put both forks and the Finder information in a single file (or container) and Apple Double to store the resource fork and the Finder information in a file and the data fork in another one.
See our page on those formats for more information.
Our programs MacDisk and MacImage can produce and convert such files.
See also our page on Mail Attachments and on our utility MacMail for more information.