What are resource forks in Mac OS X? How can they be used? What applications are using them? Are they being deprecated? Are developers encouraged to make use of them? Are they the future? Why is there a lack of up-to-date documentation? These are just a handful of questions that I had about the underlying Mac OS X filesystem. It took me several hours and hundreds of Google queries only to return with conflicting information. Through a process of gleaning information from hundreds of emails on mailing lists and usenet groups, sifting through outdated documentation, and hands-on experimentation I formed a coarse understanding of this technology. The following are my compiled observations which may or may not be correct.
I am writing this under the assumption that the target system in question is running the HFS+ filesystem.
Extended attributes vs. resource forks
First, I present an excerpt from the Wikipedia page on Resource forks:
The resource fork is a construct of the Mac OS operating system used to store structured data in a file, alongside unstructured data stored within the data fork.
From what I have gathered, there was a distinct difference between resource forks and extended attributes at one point. However, this appears to no longer be the case as I will attempt to explain in the next section. In short, the terminology usage has become muddied, and this seems to be the source of most confusion.
Resource forks are being deprecated
There is quite a bit of noise saying that resource forks are going away. Based on the information I found, this assertion is only partly true. Indeed, resource forks have already been phased out by way of Apple silently changing the underlying API implementation. Whereas this information was previously stored in the resource fork, it has now been moved to the data fork. From what I can tell, the majority of this data now manifests in the “Resources” directory that can be found within application bundles. However, there is still more resource fork data and this is now stored as an extended attribute under the key “com.apple.ResourceFork.”
At this point I must interject that it appears that Mac OS X continues to support named forks. There does not seem to be any limits on the number or size that these may be, but I’m not aware of any applications that make use of them. The majority of metadata appears to be contained within the extended attributes tree. This metadata is key-value based and generally very small in size.
Below is a bullet list of my observations.
- Apple’s resource fork was simply one of the many different forks that the Mac OS X filesystem can apparently handle.
- Apple’s resource fork is dead, but
- Apple’s APIs for interacting with their resource fork now store this information as an extended attribute (com.apple.ResourceFork) rather than using a separate fork.
- Mac OS X continues to support named forks.
- I have not seen any applications (Apple or otherwise) that use a named fork beyond the original resource fork.
- Extended attributes are used extensively by Apple products.
Accessing extended attributes (EA) and thereby com.apple.ResourceFork
Apple provides an API for interfacing with extended attributes, but they can be accessed without writing an application by using Terminal and the xattr command. For example, xattr -p com.apple.ResourceFork example.txt will display the data of the com.apple.ResourceFork attribute [if it exists]. Using the @ option with the ls command will give you a listing of all attribute keys for each file [e.g. ls -la@].
A neat trick that is still available in Mac OS X Leopard [10.5] from the days when ResourceFork was stored in its own fork is using ..namedfork/rsrc. If you don’t provide a name for the fork, then it defaults to Apple’s ResourceFork. For example, cat example.txt/rsrc will produce the same output as xattr -p com.apple.ResourceFork example.txt.
File sizes calculated in terminal do not include the size of extended attributes, including the ResourceFork. This must be obtained separately through alternative means. For example, using ..namedfork/rsrc.
Clear as mud
I hope that this article sheds some light on the situation. Extended attributes are used quite a bit by Apple products. For example, Spotlight comments are stored as an extended attribute key-value pair. When a file is deleted using Finder, a key-value pair is written that indicates where the file originated. Time Machine uses extended attributes to keep track of backups, and the list can continue.
Extended attributes should not be feared and are a great way to store additional metadata. Unfortunately, support for extended attributes is not ubiquitous. Even some of Apple’s own bundled command line programs do not fully or properly support extended attributes. As such, from a programming point of view it might be wise to avoid use of extended attributes unless the data is transient. Any important data should be stored along with the file in the data fork.
Here’s hoping that EA support improves in the near future!
Please leave a comment if the information I have gathered is incorrect, or can be better clarified.