It says here...


...that the HFS+ file system in OSX supports "multiple named forks". How do I create a named fork at command line, and then how do I store data in it? Also, what are the maximum number of bytes I can place in my named fork?

3 Answers 3


Extended attributes is what you're looking for. xattr will allow you to view and modify extended attributes at the command line. Look at the man page for more details, but in brief you can write one with the following command

xattr -w com.foo.myattribute "A bunch of data" /path/to/file

  • Extended attributes are distinct from named forks. The resource fork is listed as though it's an extended attribute using ls -l@ but xattr does not let you create and manipulate arbitrary named forks. Extended attributes have a maximum size of 128K or 64M depending where you read, whereas named forks an be any size. Named forks are not well documented and the connection between them and extended attributes is poorly understood. Commented Mar 8, 2021 at 2:02

I don't know about named forks except the resource fork. I can create it like so in Terminal (Bash shell):

echo "data fork area" > /tmp/test.txt
echo "resource fork area" > /tmp/test.txt/..namedfork/rsrc
cat /tmp/test.txt
cat /tmp/test.txt/..namedfork/rsrc

I don't know about size limitations.

You can also copy a binary executable into the resource fork, and extract the bytes back out into a file, and execute that file:

cp /usr/bin/whoami > /tmp/test.txt/..namedfork/rsrc
# get ready for some bells to sound in your terminal
cat /tmp/test.txt/..namedfork/rsrc > /tmp/test.bin
chmod u+x /tmp/test.bin

Note that the whoami command is kind of weird when you do this because it's really the id command, and so when you restore it, it reverts to the id command and you can do man id to learn more about that.

  • 1
    This method creates an extended attribute with the name com.apple.ResourceFork. You can view it with the xattr command.
    – iWill
    Commented Feb 22, 2016 at 4:06
  • @iWill: Yes the newer extended attribute feature seems to provide an additional interface to the very old resource fork feature. Commented Jun 9, 2016 at 14:31

"Named forks" is something Apple was planning to implement but (as far as I can tell) never actually did. (Or at least not in OS X – I'm unsure about Classic MacOS 8/9). macOS contains various historical remnants of that earlier plan (such as the /..namedfork/rsrc syntax, the ATTR_FILE_FORKLIST file attribute supported by the getattrlist API, etc). Eventually, Apple decided to implement extended attributes instead (in MacOS X 10.4 Tiger).

Among filesystem designers, there is a philosophical dispute about how best to support arbitrary custom metadata – "named forks" and "extended attributes" represent those two different approaches. Microsoft Windows is a rather unusual example of a system which implements both – it calls named forks "alternate data streams" (or just "streams" for short).

The key difference is what the API to manipulate this metadata looks like:

  • named forks/streams: these are essentially hidden "sub-files" which can be attached to a file, and which a programmer can read/write using the same APIs as ordinary data files. One may need to invoke some special API to list them, but you can open them just like a normal file (often using some special syntax: Apple was planning on /..namedfork/, Windows just uses a : to separate the file name from fork/stream name). They have the same size limits as ordinary files–you can have a 1KB data file with a 1GB named fork/stream attached.
  • extended attributes: each file has named key-value pairs, and has a "get attribute"/"set attribute" API to access them. You cannot open/read/write these named attributes using the same API calls you use for ordinary files. The file APIs do not accept any special path syntax to refer to them. There is usually a limit on their size, much smaller than that for ordinary data files (kilobytes or megabytes rather than gigabytes)

(As an aside, Solaris unfortunately confuses things by adopting essentially the first approach but calling it "extended attributes" – and the NFSv4 protocol inherited that terminology from Solaris.)

My educated guess is that Apple was internally trying to make up its mind between those two options, and originally was aiming at the first, but before they'd actually shipped the first option, changed their mind to the second, and the second is what actually ended up shipping.

Apple reused some of the filesystem data structures in HFS Plus originally intended to support "named forks" to implement "extended attributes". Given that fact, and given that "extended attributes" is the replacement for "named forks", you will occasionally find people treating the two terms as synonyms, making statements such as "ls -@ lists named forks". While I understand the reasons for doing that, I think it causes confusion, because the vestigial APIs in macOS which were intended to support named forks don't work for extended attributes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .