For all its irritations, macOS is still packed full of delights, and still insanely great. Last week I have mainly been exploring a feature which is so well-hidden that many advanced users don’t even know of its existence: the extended attribute, or xattr.

They started as one of the many renegade features in Classic Mac OS, when it still had a capital M and a space: the resource fork. Other duller, more popular operating systems just had flat files consisting of amorphous data. Each file on the Mac could consist of two parts, or forks – a standard flat data fork, and a resource fork.

Resource forks were wondrous, because they consisted of structured resources. They were mostly used by System files and applications (as they were known then). Applications used them to define their menus, windows, dialogs, and more. As they were completely unsigned and available for us to tamper with, we could doctor most of the interface elements as we wished.

In those days, Apple seemed to want to empower users, and provided a free editor for all those structured resources: ResEdit. It was even extensible, allowing the user to add resources to it to support the editing of non-standard resource types.

When Mac OS X arrived, resource forks were a bone of contention. They weren’t actually unique to the Mac, as other file systems supported forks too, although I don’t know of any which used them for resources in quite the same way. For a while, resource forks were under threat, as the NeXTSTEP/Unix wizards tried to bring such idiosyncrasies under control.

Resource forks broke many of the standard Unix tools, including the archiving command tool pax. One of my first tasks in Mac OS X was to hack the open source for pax to get it to handle resource forks properly, in what I called hfspax. I had intended to create a proper GUI front end for it, an app destined to be called BackXwing, but pax didn’t prove to be as useful as I had hoped, and it all ran out into the long grass. Another developer picked it up and made a success with it for a while before he too realised that pax wasn’t a winner, resource forks or not.

Resource forks not only stayed in Mac OS X, but the capabilities of HFS+ for other, arbitrary, forks were opened up somewhere around OS X 10.4. The end result is an ingenious way to associate metadata with files and folders: extended attributes. If you think of a resource not as a fork off a file, but as a chunk of metadata of type com.apple.ResourceFork, you can see how you can also have all sorts of other, structured metadata stored as extended attributes.

That is exactly what macOS does, using the features built into its HFS+ file system and now in APFS too.

Third-party developers can define and use their own types of metadata, although very few seem to bother. One reason is that working with metadata is not as straightforward as using regular data. There’s only really one tool which does anything effective with metadata, the command tool xattr, and even a simple task like copying one item of metadata from one file to another is absurdly complex. You have to read the xattr from the source in hex format, then write that to the destination, also in hex format.

You can’t just type
xattr -c com.apple.FinderInfo thisitem thatitem
but have to use something like
xattr -wx com.apple.FinderInfo "`xattr -px com.apple.FinderInfo thisitem`" thatitem

Apple still doesn’t provide convenient Objective-C or Swift wrappers to function calls to work with xattrs. There’s no metadata editor, nothing like ResEdit, and Apple seems to prefer to keep xattr use to its own engineers and their products.

Forks and extended attributes are the sorts of features that should bring developers and advanced users to macOS, just as Mac OS’s resources and ResEdit used to do. They should be empowering us, not hidden away like a skeleton in a cupboard.