At this stage in Apple’s annual macOS cycle, attention to the current version is starting to fade as all eyes turn to WWDC in June. Bugs discovered now seldom make it to the last updates of the dying cycle, unless they’re critical. Purely by chance, this week’s harvest has brought three bugs of contrasting types and severity.

Finder’s Get Info file sizes

Eight years after APFS was introduced in High Sierra, the Finder’s Get Info dialog still reports the total size of a file inaccurately, omitting in its total the size of all a file’s extended attributes.

Here Get Info claims this crafted test file is 263,195 bytes in size, but according to figures obtained from the file system, there are 183,136 bytes of data and 161,326 bytes of extended attributes, making a total of 344,462 bytes. This substantial error results from the size returned in the URL resourceValue for totalFileSize. Apple now defines that as “the total displayable size of the file, in bytes. The allocated size in bytes may include space used by metadata.” Six years ago, though, it claimed that it was the “Key for the total displayable size of the file in bytes, returned as an NSNumber object (read-only). This includes the size of any file metadata.”

In this case, totalFileSize includes around half the extended attributes, not all of them. Thus the bug is ultimately caused by the vague inaccuracy of totalFileSize being any number between the data size and the actual total size including all extended attributes. Had anyone checked this against a test case, the error would have been obvious, as it has been for at least the last six years. Instead of Apple fixing the bug, it has simply changed the documentation to make it so vague that the figure could mean almost anything.

Union mount file system

Earlier versions of macOS have supported the union mount file system as expected, but Sonoma 14.4.1 doesn’t appear to behave as intended. There are old reports that it stopped working some years ago, although union mounts remain documented, and are claimed to be valid for APFS file systems.

After mounting two test APFS volumes using the commands
sudo mount -t apfs -o union /dev/disk8s2 /Volumes/union
sudo mount -t apfs -o union /dev/disk8s3 /Volumes/union
we’d expect their contents to be the union of the contents of individual volumes, allowing for overlay of items with identical names. In the test case, that should be:

• a.text from Volume1
• b.text from Volume2, overlaid on b.text from Volume1
• c.text from Volume2

But listing the union mount using
ls /Volumes/union
shows only the contents of the second, Volume2
b.text c.text
The Finder is even more confusing, though, as it shows both Volume1 and Volume2 separately, each with the contents of Volume2.

Although the underlying cause isn’t clear yet, had anyone tested union mounts in Sonoma 14.4.1, this problem would have been obvious.

XProtect Remediator

While those two bugs could be considered to be of relatively low importance, as there other ways of obtaining accurate total file sizes, and union mounts appear little-used in macOS, the third bug was more severe, and of greater consequence. XProtect Remediator version 132, released on 30 April, incorporated changes in the detection of Pirrit malware that often give false positives with components in Xcode, and with some third-party security software.

Apple’s response was very quick, and a revised version 133 of XProtect Remediator was released early on 2 May to address that. There are, though, reports that problems persist with some third-party security software, and a further update may be required to resolve those.

False positives are a constant problem in malware detection, making testing for rule specificity an essential step before releasing updated rules. What is a little odd here is that false positives generated by Xcode should surely have been discovered had the new rules been tested on Macs with Xcode installed with support for operating systems beyond macOS.

Trick or treat

These three bugs serve as a microcosm of the problems Apple has with macOS.

In the first case, rather than fix a longstanding bug in the macOS API, the documentation of totalFileSize has been rendered so vague that it doesn’t represent total file size in any useful sense of the term, leaving the Finder displaying nonsense. In the second case, the documentation makes a promise that hasn’t apparently been fulfilled for some years, in the hope that the feature is sufficiently obscure that no one notices that it doesn’t work any more.

We should be more optimistic about the third case, of XProtect Remediator’s Pirrit scanner turning cannibal against Xcode simulator runtimes. What’s disquieting here is that the offending scanning module in version 132 could only have been tested on Macs with Xcode installations for macOS alone, as they don’t have simulator runtimes. The saving grace was the dedication of Apple’s security engineers, who must have worked continuously until they had fixed that unfortunate bug in an app that still doesn’t officially exist.