My two previous articles described how xattr flags can check whether individual extended attribute types (xattr) types are copied in the Finder, and to and from iCloud Drive, and how apps can use them to preserve custom xattres on documents. What remains is to determine how different types of copying interpret these flags and how they affect other parts of macOS such as Finder and, most importantly, Spotlight search.
Jonathan Levin – who of course knows all about these and has now added a short section on them to Volume I of his reference books on Apple's operating systems – points out that the xattr flags only affect copying behavior under
copyfile (3) API. That means that copies made with Finder will respect them, and will strip xattrs where instructed, but
cp in Terminal does not, and preserves all xattrs regardless of their flags. Of course, it can be a mixed blessing.
When using custom xattrs, you're probably not worried about other parts of macOS being able to handle them properly, except perhaps for Spotlight searches. Typically, metadata indexing does not include custom xattr content, but it is (I believe) possible to write a custom metadata importer to handle them. However, I do not know whether such indexing would work with xattr flags.
When I looked at Spotlight, I was prepared for problems, but to my amazement, indexing of standard xattrs works normally when they are flagged. [1
com.apple.metadata: kMDItemxattrs which is 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 follows: macOS, to ensure they are preserved during copying and synchronization, but not during export. In my original work on xattr conservation, I found that they were preserved during transportation through iCloud Drive, so there seems to be little point in linking an overriding S flag in practice.
When I then attached the flag S to each of these xattres, Spotlight was still able to find the contents of the flagged xattrs . This shows that metadata indexing is aware of the xattr flag system, and provided that a xattr type is norma lly indexed for Spotlight, the indexing is not disturbed 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 Finders Get Info dialog. Adding a flag to these xattrs makes them unavailable to the Finder, which is clearly not aware of the xattr flag system, and sees them as having different names instead of flags. 
So to summarize:
- Using xattr flags, apps can easily preserve metadata for private files transmitted through iCloud Drive. The biggest problem here is that xattr-type names are not handled transparently by features like
getxattr ()and it is up to each app to handle them properly.
- Xattr flags will affect copying of files using Finder and other r methods depending on
copyfile (3)API, but Terminal's
cpnormally copies all xattrs whatever the flag.
com.apple.metadata: kMDItemxattrs are treated as if they already have PS flags, and are preserved during transport through iCloud Drive.
- Indexing the spotlight metadata seems to take into account the use of xattr flags, and indexes still xattrs with flags correctly.
- The Finder's Get Information dialog does not handle the xattr flags correctly; Placing flags on a xattr type normally displayed by the Finder will make it unavailable.
I hope they help you decide whether and how to use the xattr flag.