File data is permanent but mutable: when you open a document, you expect its content to be exactly the same as when you last saved it. Metadata is different in this respect: file attributes such as the date the file was last opened should be updated, and extended attributes (xattrs) have varying requirements for their persistence. Some metadata are disposable, and you don’t want them to propagate to copies of that file, while others need to remain sticky and go with it as long as possible.

As far as I’m aware, macOS is the only general-purpose operating system which has inbuilt mechanisms for managing the persistence of its metadata, and those are supported by its two native file systems, HFS+ and APFS. This article explains how this, one of the best-kept secrets of macOS, works.

Now you see it…

To see how to make xattrs vanish magically, you’ll need a minimum of my free app Metamer, which edits them one at a time. If you’re already experienced with xattrs, then you’ll find xattred even better for this demonstration, and the command line wizards can follow along using xattr as they wish. To do this, you need two simple test files, which might just as well be plain text containing a token amount of data. I like working with text using BBEdit, which also adds a minimum of xattrs; TextEdit gets a bit carried away at times.

Open your first test file using Metamer, set its Combo Box to the Comment item, type in a comment in the box below, and click Save. That’s added a standard comment xattr of type com.apple.metadata:kMDItemComment, which you should see displayed in the Finder.

Make a few copies of your test file in various places, and then inspect their xattrs. This is easiest using xattred, but you can still open them using Metamer and switch the Combo Box to read Comment: your comment should be shown below. By default, com.apple.metadata:kMDItemComment xattrs are preserved in most operations which can cope with xattrs. This makes them a good choice for storing metadata which you want to persist, and why they’re in Metamer’s menu.

…now you don’t

With your second test file, repeat the same process above, but this time instead of selecting the Comment item in Metamer, type com.apple.metadata:kMDItemComment#N into the Combo Box, type in your comment below, and click Save.

You can then inspect that xattr, either using xattred, or in Metamer. In the latter, instead of opening the test file and selecting the Comment item, you have to type com.apple.metadata:kMDItemComment#N into the Combo Box and press the Tab key. Notice how that xattr remains in the original file, but vanishes from most copies made of that. What’s unfortunate is that the Finder isn’t smart enough to recognise that a com.apple.metadata:kMDItemComment#N is actually still a comment.

So appending #N to a xattr’s name makes it ephemeral, and that xattr isn’t copied when the rest of the file is.

How macOS manages the persistence of metadata

For the last seven years, macOS has had an inbuilt mechanism for managing the persistence of extended attributes. It’s found still in the open source components distributed by Apple, in the copyfile component, where the relevant code is in xattr_flags.h and xattr_flags.c. For convenience I have summarised the relevant sections in the Appendix at the end of this article.

The persistence of any xattr is determined by appending flags to the name of the xattr type, a technique you may already have seen in use in the com.apple.lastuseddate#PS xattr, which is widely used. The hash sign # marks the start of what Apple refers to as a ‘property list’, but to avoid confusion I’ll call flags.

The N flag you used in the demonstration above ensures that xattr is never copied, so is ephemeral, and will remain attached to the original file, but not its copies. The PS flags used with com.apple.lastuseddate ensure that it’s normally preserved during copying, and even in syncing, making it sticky.

Two sets of defaults are defined, one for files which aren’t sandboxed, the other for those which are; these only differ in the handling of xattrs with types starting com.apple.security. The quarantine flag, com.apple.quarantine, is set to be maximally sticky, as we’ve all experienced. I use the same flag technique in my apps Fintch, Dintch and cintch to ensure that the xattrs those add to files to check their integrity are preserved when those files are copied or moved. It’s a simple but highly effective technique.

The snag is that few Apple engineers seem aware of this valuable feature, so these flags usually aren’t handled correctly. Just as with the Finder now, com.apple.metadata:kMDItemComment#N should be treated as a xattr of type com.apple.metadata:kMDItemComment with the flag N. Instead, it’s treated as a xattr with a different name. Presumably this is because Apple never got round to properly documenting this unique system for managing the persistence of metadata, and it has simply been forgotten. By Apple’s own engineers.

Appendix: macOS Metadata Persistence Flags

Flags consist of one or more characters following a hash # appended to the type name of the xattr. For example, the xattr named com.apple.lastuseddate#PS is properly of type com.apple.lastuseddate with the flags PS.

Flags can be upper or lower case letters C, N, P and S, and invariably follow the # separator, which is presumably otherwise forbidden from use in a xattr’s name. Upper case sets (enables) that property, while lower case clears (disables) that property. The properties include:

• C: XATTR_FLAG_CONTENT_DEPENDENT, which ties the flag and the file contents, so the xattr is rewritten when the file data changes. This can be used for checksums and hashes, text encoding, and position information. The xattr is preserved for copy and share, but not in a safe save.
• P: XATTR_FLAG_NO_EXPORT, which doesn’t export the xattr, but normally preserves it during copying.
• N: XATTR_FLAG_NEVER_PRESERVE, which ensures the xattr is never copied, even when copying the file.
• S: XATTR_FLAG_SYNCABLE, which ensures the xattr is preserved even during syncing. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this will override that default.

These must operate within another general restriction of xattrs: their name cannot exceed a maximum of 127 UTF-8 characters.

There is a set of system defaults which is baked into the xattr flag code, where the following default flags are set for different types of xattr (* here represents the wild card):

• com.apple.quarantine – PCS
• com.apple.TextEncoding – CS
• com.apple.metadata:* – PS
• com.apple.security.* – S for files which aren’t sandboxed, but N for those which are sandboxed
• com.apple.ResourceFork – PCS
• com.apple.FinderInfo – PCS

Full details are in xattr_flags.h and xattr_flags.c in the copyfile archive in Apple’s open source for macOS.