When you copy a file to iCloud Drive, then copy from there onto another Mac, the contents of the file move across unaltered, don’t they?

No they don’t, at least not if one Mac is running Sierra 10.12.6, and the other High Sierra 10.13.2. If you try that, you’ll probably discover that most of the file’s extended attributes (xattrs) vanish in the copying.

TL;DR: Don’t use iCloud Drive as a means of copying or sharing documents between Sierra and High Sierra, as they may well lose metadata in the process.

A simple test requires two Macs, one running High Sierra 10.13.2, the other Sierra 10.12.6, connected to the same iCloud account, thus accessing a common iCloud Drive. On one Mac – it doesn’t matter which one – take a small text file and paste it a custom icon. To do that, find a file with a custom icon, such as an image thumbnail, and copy and paste between the top left icon images in the Finder’s Get Info dialog for them. So you start off with this:

and end up with this:

Keep a copy of that modified file somewhere safe, and copy it across to your iCloud Drive. Once there, it should continue to show the same custom icon to that Mac, using that same version of macOS.

Then, inspect the same file on the same iCloud Drive on your other Mac, using the different version of macOS. Not only is the custom icon nowhere to be seen, but the file size is smaller, the same as it was before you pasted in the custom icon. Try copying the file onto local storage, and you’ll see that your custom icon has gone for good.

If you fancy a more sophisticated and functionally-significant test, download and install a copy of Skim from here onto both Macs. Open a PDF in Skim on one, add some annotations, save the modified document, and copy that across to your iCloud Drive.

Download it onto the other Mac, and Skim won’t be able to find any of those annotations. They too will have gone, because in the process of transferring the file via iCloud, the extended attributes used to store those annotations have mysteriously vanished.

What should happen?

According to Apple’s File System Programming Guide, which was last revised just over a year ago:
Apps create files and directories in iCloud container directories in exactly the same way as they create local files and directories. And all the file’s attributes are saved, if they add extended attributes to a file, those attributes are copied to iCloud and to the user’s other devices too.

This is a reasonable expectation, and I have been unable to find any list of xattrs which are not supported by iCloud Drive, nor when transferring files between Sierra and High Sierra. Nor does it make any sense that only certain xattr types are supported: what works for one type should work for any other.

What exactly does happen?

I have examined files with a rich collection of extended attributes, under 10.12.6 and 10.13.2, on local storage and in iCloud Drive. This confirms that most xattrs are stripped by iCloud Drive in this fashion.

Xattrs removed include:

• com.apple.FinderInfo
• com.apple.metadata:_kMDItemUserTags
• com.apple.ResourceFork
• com.apple.serverdocs.markup
• net_sourceforge_skim-app_ series
• net_sourceforge_skim-app_notes
• net_sourceforge_skim-app_rtf_notes
• net_sourceforge_skim-app_text_notes
• co.eclecticlight.[any]

Items in iCloud Drive containing any of those xattrs which were written there using the other version of macOS lose those xattrs when viewed or copied from iCloud Drive using the other version of macOS.

Xattrs which are preserved include:

• com.apple.TextEncoding
• com.apple.metadata:kMDItemDownloadedDate
• com.apple.metadata:kMDItemWhereFroms
• com.apple.metadata:kMDLabel_ series
• com.apple.quarantine

Items in iCloud Drive containing any of those xattrs retain those no matter which version of macOS they are viewed from, or the file copied from.

Why does this happen?

I have been unable to find any reference to this process in Apple’s documentation. Indeed, the only reference that I can find to the handling of xattrs by iCloud Drive (quoted above) assures developers that they are not tampered with in any way. It is therefore either an undocumented feature, or a bug.

The selectivity observed makes a bug appear unlikely. The lists appear consistent across several different tests performed at separate times over a period of a day, and are independent of the number of xattrs attached to a file, the size of the file, or its type.

Those xattrs which are stripped consist of two groups: com.apple types with older, perhaps now superceded, function such as the resource fork and Finder Info, and all third party types. This suggests that the transfer process filters xattrs by design, only permitting those on a shortlist of com.apple types to pass from Sierra to High Sierra, or back. The reason for this is obscure, but it could be suggested that there are underlying security issues for doing this.

Although we now know what Apple is doing, only Apple knows why it is doing it.

I would be very interested to hear reports from others who have replicated this strange behaviour, please. It is always possible that this is confined to a small number of iCloud accounts, or may even be unique. As there is nothing which the user can change to try to address this behaviour, I am at a loss to know what to try next, apart from transferring only compressed archives and not raw files.

Postscript (1710 UTC)

Since writing the above, I have discovered that the ‘filter’ has a more complex heuristic and will also block some xattrs listed in the whitelist above. I will explain more in my Last Week on My Mac article tomorrow.