My two previous articles described how xattr flags can control whether individual extended attribute (xattr) types are copied in the Finder, and to and from iCloud Drive, and how apps can use them to preserve custom xattrs on documents. What remains is to establish how different types of copying interpret these flags, and how they affect other parts of macOS such as the Finder and, most importantly, Spotlight search.

Jonathan Levin – who of course does know all about these, and has now added a short section about them to volume I of his reference books on Apple’s operating systems – points out that xattr flags only affect copy behaviour under the copyfile(3) API. That means that copies made using the Finder will respect them, and will strip xattrs where so instructed, but cp in Terminal doesn’t, and preserves all xattrs regardless of their flags. That can of course be a mixed blessing.

When you’re using custom xattrs, you’re probably not concerned whether other parts of macOS will handle them properly, except perhaps for Spotlight search. Ordinarily, metadata indexing doesn’t include custom xattr content, but it is (I think) possible to write a custom metadata importer to handle them. I don’t know whether such indexing would work with xattr flags, though.

Looking then at Spotlight, I was prepared for problems, but to my amazement metadata indexing of standard xattrs works as normal when they’re flagged.

To test this, I added standard com.apple.metadata:kMDItem xattrs which are normally indexed by Spotlight, including:

• com.apple.metadata:kMDItemCopyright
• com.apple.metadata:kMDItemCreator
• com.apple.metadata:kMDItemDescription
• com.apple.metadata:kMDItemHeadline
• com.apple.metadata:kMDItemKeyword

These are normally treated as if they have PS flags by macOS, to ensure that they’re preserved during copying and syncing, but not during export. In my original work on xattr preservation, I found that they are preserved during transit through iCloud Drive, so there seems little point in attaching an overriding S flag in practice.

When I then attached the S flag to each of those xattrs, Spotlight was still able to find the content of those flagged xattrs. This demonstrates that metadata indexing is aware of the xattr flag system, and provided that a xattr type is normally indexed for Spotlight, that indexing isn’t disrupted by the presence of the flag.

However, the Finder is an exception to this. Some of the com.apple.metadata:kMDItem xattrs are now displayed in the Finder’s Get Info dialog. Adding an S flag to those xattrs renders them inaccessible to the Finder, which clearly isn’t aware of the xattr flag system, and sees them as having different names rather than flags.

So to summarise:

• Using xattr flags, apps can readily preserve private file metadata which transits through iCloud Drive. The biggest problem here is that xattr type names aren’t handled transparently by functions such as getxattr(), and it’s up to each app to handle them appropriately.
• Xattr flags will affect copying files using the Finder and other methods reliant on the copyfile(3) API, but Terminal’s cp normally copies all xattrs regardless of flags.
• Standard com.apple.metadata:kMDItem xattrs are treated by default as if they already have PS flags, and are preserved during transit through iCloud Drive.
• Spotlight metadata indexing does appear to take the use of xattr flags into account, and still indexes xattrs with flags correctly.
• The Finder’s Get Info dialog doesn’t handle xattr flags correctly; setting flags on a xattr type normally displayed by the Finder will render it inaccessible.

I hope those help you decide whether and how to use xattr flags.