Ask Different is a question and answer site for power users of Apple hardware and software. It only takes a minute to sign up.
Sign up to join this community
It says here...
https://en.wikipedia.org/wiki/Fork_(file_system)#Apple
...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?
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
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.
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
/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.
"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:
/..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.(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.
