Last Week on My Mac: Why Sonoma 14.4.1 was necessary

If Apple is to rely, as it does, on developers and users reporting bugs that should have been fixed before release, then it needs at least to give us clues in release notes as to where to look. Two of the serious bugs fixed in macOS 14.4.1 last week were completely unexpected, and only discovered by chance. Here I’ll explain how one of them came to light, and what had gone wrong. You can read Aurelio Garcia-Ribeyro’s account of the other in his article on Oracle’s Java blog.

None of Apple’s release notes for Sonoma 14.4 mention any changes to iCloud Drive, the FileProvider API, or management of macOS file versions:

release notes for users inevitably lead with emoji, and contain nothing of relevance,
release notes for enterprise users also draw a blank,
security release notes don’t mention any fixes that appear relevant,
developer release notes are equally silent.

The only signs of changes that had passed in the absence of documentation are to be found in changed versions found in /System/Library, where I remarked: “There are updates to many Frameworks, including most of the Core… series, and FileProvider to a new version” and “there are extensive changes to iCloud (both CloudKit and iCloud Drive) components”.

It wasn’t until I published my detailed explanation of how iCloud Drive works in Sonoma, on 18 March, 11 days after the release of macOS 14.4, that JK spotted a discrepancy between what I described there and tests they had carried out on their Mac. That arose because the research on which I based my article had been performed in macOS 14.3 and 14.3.1, not in 14.4.

Within 12 hours I had reproduced the bug introduced in 14.4, and reported it to Apple in FB13691058. That report was addressed with great speed, and before the release of 14.4.1 I had been informed that a fix had been identified and would be implemented in a future update to macOS. That turned out to be 14.4.1, released on 25 March, almost exactly seven days after I had reported the bug, and 18 days after the release of 14.4. Sadly for the engineers who worked at speed to fix this bug, Apple’s release notes for 14.4.1 only mention the bugs affecting Java and two others. Maybe this bug was considered to be too technical to try to explain.

While I’m both impressed and delighted at the speed of Apple’s response, it would surely have been better if those bugs hadn’t been released in the first place, and that developers and users had been made aware of the changes introduced in 14.4 that were their causes.

To understand what had gone wrong in 14.4, and how serious it was, I’ll return to diagrams derived from those that led to the bug’s discovery by JK. In these, I draw distinction between four components of each file stored locally on your Mac and remotely in iCloud Drive’s servers:

file attributes, starting from its inode or iCloud Drive file number,
extended attributes or xattrs, including metadata such as tags,
data, the contents of the file,
versions, copies of previous versions of file data stored in a hidden database on local volumes.

Each of these is handled differently by iCloud Drive. Attributes are largely preserved, although iCloud Drive doesn’t use inode numbers but its own file numbers instead. Some extended attributes are copied up and preserved, but those stored locally remain there, so that only affects other Macs and devices accessing those files. Because versions are stored locally, they have been preserved on the Mac that saves them, but aren’t made available to other Macs accessing the same file using iCloud Drive.

In Sonoma 14.4, file versions are preserved only while that file remains fully in local storage. If the file is evicted and has its local data removed, not only does that make the local file dataless, but versions are lost as well. When that file is materialised again by the download of its data, as no versions are available from iCloud Drive, all its previous versions are silently lost.

For example, I have one test file with 25 previous versions. When I put that into iCloud Drive in 14.4, all those versions remain accessible from the Mac that saved them. If that file is evicted from local storage, either by the user or by macOS, then all 25 versions have gone forever, and can’t be downloaded from iCloud Drive. Nor can they be restored from local backups of that file, as backups can’t back up file versions.

This is what should have happened in 14.4, and does again in 14.4.1: local file versions remain through the cycle of eviction and download (materialisation).

If I were to perform Root Cause Analysis on what happened here, there are several failures that Apple needs to address if it wants to prevent this seemingly relentless succession of bugs. I hope I don’t need to spell them out.

Thanks to JK for reporting this in the first place, and to the engineers who fixed it so quickly, and ensured 14.4.1 was released within a week of my report. This also demonstrates how important it is to report bugs to Apple using Feedback.