What are the APIs for working with HFS+ named forks?

Question

I know that resource forks are deprecated in Mac OS X.

It's not clear whether the less well known and little used named forks are also deprecated. HFS+ actually supports an arbitrary number of arbitrary length forks for any file. (Mac's named forks are conceptually similar to Windows's alternate data streams or "ADS".)

Deprecated or not there's still reasons to learn about creating, enumerating, removing, and otherwise manipulating file forks.

Yet I can't seem to find anything about the APIs for working with forks.

All I can find is that from the terminal and perhaps other places that accept filenames or paths you can access the resource fork with the syntax <filename>/..namedfork/rsrc and until recently also <filename>/rsrc. I have tried replacing rsrc with other names but all the commands I tried in the terminal failed.

Where can I find old or unofficial documentation on the APIs to work with named forks in OS X programatically?

By the way there seems to be a common misunderstanding on the internet when Googling this topic. Random punters are saying that named forks are built on named file attributes. This is not so. Named file attributes are a fairly new OS X feature. Named forks predate OS X. It seems that in fact named file attributes could well be using named forks behind the scenes.

In any case, please don't submit answers about named file attributes. I am specifically seeking information on arbitrary named forks.

---

There is some description of named forks in section 12.7.4. "The Attributes File"

Answer 1

My old answer is wrong! Three years later there is now more information on the internet, including mirrors of old and deprecated Apple developer documentation.

Here's a selection of the APIs for named forks I've found:

Opening Files

• FSOpenFork Opens any fork of a file or directory for streaming access.
• PBOpenForkSync Opens any fork of a file or directory for streaming access.
• PBOpenForkAsync Opens any fork of a file or directory for streaming access.

Creating and Deleting Named Forks

• FSCreateFork Creates a named fork for a file or directory.
• PBCreateForkSync Creates a named fork for a file or directory.
• PBCreateForkAsync Creates a named fork for a file or directory.
• FSDeleteFork Deletes a named fork from a file or directory.
• PBDeleteForkSync Deletes a named fork from a file or directory.
• PBDeleteForkAsync Deletes a named fork of a file or directory

Iterating Over Named Forks

• FSIterateForks Determines the name and size of every named fork belonging to a file or directory.
• PBIterateForksSync Determines the name and size of every named fork belonging to a file or directory.
• PBIterateForksAsync Determines the name and size of every named fork belonging to a file or directory

Manipulating File and Fork Size

• FSGetForkSize Returns the size of an open fork.
• PBGetForkSizeSync Returns the size of an open fork.
• PBGetForkSizeAsync Returns the size of an open fork.
• FSSetForkSize Changes the size of an open fork.
• PBSetForkSizeSync Changes the size of an open fork.
• PBSetForkSizeAsync Changes the size of an open fork.

Core Services Framework Reference

Answer 2

After spending quite a few hours on this I believe I can safely come to this conclusion:

• HFS+ does support arbitrary named file forks.
• Mac APIs have however never included public APIs to work with any other forks than the data fork and resource fork.

Sorry I don't have specific links to support my findings. I basically built up a picture by looking at many pages on apple.com and many other diverse pages.

But in particular most APIs relating to forks exist in pairs where one is for data forks and the other is for resource forks. When APIs consume or return data about forks it is done with a numeric field that can only have two legal values and never an arbitrary string representing a fork's name.

Answer 3

The old File Manager was able to do this. Unfortunately, the docs don't seem to even be in Apple's Retired Documents Library.

So, you'll have to look at the headers, which are pretty well documented. See /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h. In there, you will find, for example, FSOpenFork(), which takes an arbitrary fork name. Note, though, that the comment documenting it says, "All volumes should support data and resource forks. Other named forks may be supported by some volumes." (Emphasis mine.)

Once you have a fork reference number from FSOpenFork(), you can use FSReadFork() to read from it, etc.