I hope that you enjoyed Saturday’s Mac Riddles, episode 332. Here are my solutions to them.
1: I came in 1998, Bondi blue with USB.
Click for a solution
iMac
I (the start of its name) came in 1998 (it was released on 15 August 1998), Bondi blue (the colour of the first model) with USB (it was the first with USB ports).
2: I came a year later, with a PowerBook ID and AirPort.
Click for a solution
iBook
I (the start of its name) came a year later (it was released on 21 July 1999), with a PowerBook ID (its model ID was PowerBook2,1) and AirPort (it was the first with built-in Wi-Fi).
3: I came two more years later, with the smallest hard disk and LCD, and a thousand songs.
Click for a solution
iPod
I (the start of its name) came two more years later (it was released on 23 October 2001), with the smallest hard disk (5 GB) and LCD (2 inch), and a thousand songs (its launch tagline was ‘a thousand songs in your pocket’).
The common factor
Click for a solution
They each start with the letter i, something initially hated by Steve Jobs, and were aimed at the consumer.
For good practical reasons, provided an app was signed using a certificate that was valid when the developer signed it, that certificate remains valid in perpetuity unless Apple (as the Certificate Authority) revokes it. But signatures in installers, including those for macOS and its components, must be valid when you run that installer. When any of the certificates used in Apple’s installers expire, Apple has to release a new installer with a certificate that remains valid into the future.
Six years ago, on 24 October 2019, Apple’s intermediate security certificate it had been using to sign all macOS installers and updaters expired. That also applied to most if not all Apple’s user signing certificates, but not the Apple Root CA. The consequence is that none of the installers provided with certificates expiring in 2019 will work on Macs running with a more recent date.
To check whether an installer is affected, double-click it to open it in the Installer app. At the top righthand corner of its window is a small padlock: click on that to review its certificate information. Most Apple installers refer to three levels of certificate:
Apple Root CA, the root certificate authority, should expire in 2035.
Apple Software Update Certification Authority provides the intermediate certificate, which may have expired on 24 October 2019.
Software Update, the user certificate, may also have expired on 24 October 2019.
Normally it’s number 2 above that is the most critical: once an intermediate certificate has expired, all chained user certificates become invalid. Currently, the intermediate certificate for all third-party developer certificates doesn’t expire until 2027. It’s unclear why Apple gives its own certificates an intermediate that expires after less than five years, and you might recall the previous time this happened was in February 2015.
If you have an old Mac and want to install or update macOS on it, using an old installer package with expired certificates will fail. To work around that, you’ll need to locate an installer with updated certificates that remain valid on the date that you perform that installation. There are several ways to accomplish that, with an excellent compilation given by Mr. Macintosh.
One popular way of working around this is to deliberately set your Mac’s clock back to a date before those certificates expired, such as 20 October 2019. Although that’s easy to do, it has far-reaching consequences that you should consider before trying it.
A great deal of macOS depends on the accuracy of date and time stamps. For example, it’s a general rule that the creation timestamp of a file or directory should be the same as or earlier than its modification and other timestamps. Some software used to make backups may become confused with file creation times that are not only more recent than their modification timestamp, but are also more recent than the current clock time. This can also feed through into the FSEvents database used by Time Machine to determine what it should back up, and more.
Macs suddenly running at some time in the past create difficulties in the log as well. You may well discover that log entries written at times set to be days or years ago can’t be found, particularly if you do later return that Mac to correct time. That’s another decision you need to think through carefully: once you have run the outdated installer, will you return the clock to normal timekeeping, so it leaps forward by more than 6 years?
As a general principle, don’t try fiddling with your Mac’s clock to pretend it’s a time in the past. That may leave you a mess that is too deep-seated to be put right.
Last week I drew attention to problems interpreting the timestamps of files in macOS, generating lively discussion with Chris and Richard. Although the gist of that article stands, it was clear that there remained several issues, and this sequel tries to address those better, with the aid of a new app, Dropera 2. The TL;DR for this article is that timestamps are even more complicated than I previously described.
The first task was to develop a tool for reading and recording these timestamps reproducibly. Although the four key timestamps are exposed in Precize, opening a file in that app is likely to change at least one of them. For a substitute I turned to an earlier SwiftUI demo, Dropera, with its drag-and-drop support to handle file URLs without opening, reading or otherwise changing the file.
Timestamps
This new version of Dropera had then to read the right timestamps and convert them into accessible dates and times. For some timestamps, we’re spoiled for choice: time of creation of a file, shown in the Finder as Date Created, is saved in an APFS file’s attributes as create_time, exposed in the stat command as st_birthtime, and accessible within an app’s code as the NSFileCreationDate file attribute or creationDate URL resource. To establish which timestamp is which, I have compiled a table giving the sources I have been able to discover.
For Dropera, following careful comparison with the values delivered in stat, I selected:
Creation from NSFileCreationDate
Modification from NSFileModificationDate
Attribute modification from attributeModificationDate
Access from contentAccessDate.
The last two aren’t available in the Finder or elsewhere in the GUI, while the Finder does provide Date Last Opened, Date Added and Content Created:
Date Last Opened isn’t related to Access Time, but is recorded in the com.apple.useddate extended attribute. Unfortunately, adding and manipulating that may change the Attribute Modification timestamp, so has to be avoided. As Apple doesn’t appear to document the xattr or its interpretation, I have avoided looking at it any further here.
Date Added is the timestamp when a file was added to its current directory. As that isn’t strictly speaking a file attribute, I will ignore it here.
Embedded records of Content Created require file data to be read, so accessing them is likely to update at least one of the key timestamps.
Each of those three is available from the metadata indexed by Spotlight, but that’s an indirect and unreliable way to access them.
Using Dropera
To use Dropera to read the four key timestamps just drop the file onto its window, and the app will then display the filename, its path, and the four timestamps in the order of Creation, Modification, Attribute modification and Access times.
Adjust the window width to make these most convenient to read. The layout shown above is compact and automatically splits each timestamp into date and time components. In other uses, you might prefer to widen the window so each entry takes a single line.
To refresh the values shown for the current files, click on the Refresh tool. Although the window continues to display just the single set of entries, the previous timestamps are saved in memory, and the whole history since the last drag-and-drop onto that window can be exported to a text file using the Save as text tool. You can also select the line of results, copy and paste that into another app if you prefer.
Drop multiple files onto Dropera’s window and all their timestamps will be shown. You can then select continuously (Shift-click) or discontinuously (Command-click) to copy those values, and Refresh them.
Demonstration
Open TextEdit, create a new file and set its type to plain text. Add a few words and save it somewhere convenient. Then open Dropera, and drop that file onto its window to inspect its timestamps. They’re likely to show Creation and Modification times the same, Attribute modification slightly later, and Access another second or so afterwards.
Next make a small change to that document and save it. Click Dropera’s Refresh tool and only the Creation time remains unchanged. Close that document in TextEdit, and Refresh the times again to confirm that none have changed. Now select the file in the Finder so its QuickLook thumbnail is previewed. When you Refresh its times, you should see its Access time has been updated. Now double-click the file to open it in TextEdit, and check times again while the file is still open. Attribute modification and Access times are altered, but remain the same after you have closed the document. Export those records as a text file, and you should see:
Creation time remains unchanged throughout.
Modification time changes once, when the second version was saved.
Attribute modification time changes twice, when the modified file was saved, and when the file was reopened.
Access time changes three times, the additional occasion being when you viewed the document’s thumbnail in the Finder.
Dropera 2, which requires macOS 14.6 or later, is available from here: dropera20
I hope that you enjoyed Saturday’s Mac Riddles, episode 331. Here are my solutions to them.
1: A red Canadian named by Jef and after John came in 1984.
Click for a solution
Macintosh
A red (the fruit is also known as the McIntosh Red) Canadian (it’s the national apple of Canada) named by Jef (the Macintosh was named by Jef Raskin after his favourite apple) and after John (the apple is named after John McIntosh, who discovered it in 1811) came in 1984 (when the first Mac was released).
2: A wonder for cooking led by Larry came in 1993.
Click for a solution
Newton
A wonder (the fruit is known as the Newton Wonder) for cooking (it most commonly is, as it’s too sour for eating uncooked) led by Larry (Apple’s Newton development was led by the late Larry Tesler) came in 1993 (Apple’s Newton was released in 1993, and it was abandoned in 1996).
3: This fruit from Newtown flopped between 1996-97.
Click for a solution
Pippin
This fruit (another apple) from Newtown (the apple is the Newtown Pippin) flopped between 1996-97 (Apple’s Pippin was released in 1996, and abandoned the following year).
The common factor
Click for a solution
They are each Apple products named after varieties of apple fruit.
For the last seven years or so there have been many folk complaining that Spotlight local search hasn’t been finding the files they know are there. Many have resorted to repeatedly rebuilding its indexes, usually without success. Last week, thanks to Jürgen, Drew, aldous and others who have contributed, we have discovered one cause. A bug that appears to have been introduced in macOS Mojave, and is still present in Tahoe 26.0.1, that prevents Spotlight from indexing any of the contents of plain text files that start with certain characters.
Jürgen stumbled across the first example, with files starting with the two capital letters LG. At the time, that seemed extremely unusual and unlikely to affect many files. Then Drew added HPA and Draw to the list of forbidden characters. What looked like a rare event was becoming increasingly commonplace, and that list can only grow. How many indexing failures it could account for is impossible to guess.
Piecing together the evidence, it looks like this bug is inside the standard macOS RichText.mdimporter, now embedded in the Signed System Volume in /System/Library/Spotlight and at version 6.9 (350), as it has been since Sonoma (Ventura 13.7.8 has build 345.60.106, although that also suffers this bug). What happens is that saving a text file starting with forbidden characters correctly triggers Spotlight’s indexing service. That identifies the file as having the UTI public.plain-text and hands it over for its contents to be indexed. But the indexer inspects those first few characters, decides it’s a different type of file altogether, and promptly returns an error 4864 for an NSCoderReadCorruptError without going any further.
Apart from the text content not being added to Spotlight’s indexes, and a few lines buried in the Unified log, there are no indications of anything going wrong. If you test the importer using mdimport -t -d3 filename
the file appears to import correctly, but that command doesn’t give any insight into the import of its contents, only standard attributes such as the filename that are indexed separately.
It was Drew who first suggested a plausible reason for this failure, confirmed by aldous: prior to attempting to index the text contents, Spotlight’s service was using a completely different method to check the type of the contents, the ‘magic’ database used by the file(1) command.
file(1) is an old Unix utility dating back to 1973 or earlier, operating independently of UTIs that were adopted in Mac OS X 10.4 Tiger 20 years ago. Rather than relying on a type assigned to a file, it ‘sniffs’ the contents, particularly the first few bytes of data, and uses a sprawling set of ad hoc rules to guess the file type. It turns out that files starting with the characters Draw were characteristic of a binary vector graphics format used by the !Draw app for RISC OS 2 in 1989. Rather than believing the file’s UTI for one of the most common types of files in macOS, Spotlight’s indexer therefore decided that it was trying to import file data that must now be as rare as hens’ teeth, and wouldn’t go any further.
If you’re sceptical about this coincidence, open the acorn magic data in /usr/share/file/magic in a text editor, and you’ll see the file opening string of Draw identified as RISC OS Draw file data. There are 332 other magic data files containing similar rules for identifying file types. I leave it as an exercise to the Unix wizard to build a list of all those that could cause similar problems with Spotlight indexing.
When this bug hunt started and it affected just LG and HPA, it was fairly esoteric and faintly amusing, at least as long as you didn’t write about your LG TV, high pressure air or Horizontal Pod Autoscaling. When Draw was added, and all those 333 magic files piled in, I realised how extensive this could be, and how little testing can be performed on Spotlight indexing and search.
Given that about eight years ago an Apple engineer wrote code for the RichText.mdimporter in macOS that introduced testing against some or all of the magic database, wouldn’t you have thought they’d test and debug that against test cases, such as text files starting with characters (mis)recognised by magic rules? And maybe occasionally over subsequent years and new versions of macOS, wouldn’t revised versions of the importer be tested again?
Apple likes Spotlight to be opaque to the user, for it to ‘just work’. There’s almost no documentation even for developers, and tools provided are strictly limited in what they can do, as demonstrated here in the case of mdimport. That’s all very well until Spotlight doesn’t work and no one outside Apple can do anything about it. Third-parties can’t even write custom mdimporters to do the job properly, as those bundled in macOS take priority.
If this was the first time that Spotlight indexing had let us down, I might feel more charitable. But between macOS Catalina 10.15.6 in July 2020 and Big Sur 11.3 in April 2021 macOS was incapable of indexing the content of any Rich Text files. There are still many documents that haven’t been indexed as a result. Those whose contents haven’t been indexed as a result of this bug will similarly be excluded from search until they too are reindexed by a fixed mdimporter. For Intel Macs that won’t be supported by macOS 27, that could well be forever.
Timestamps on files and folders are important, and can be used for many different purposes, from sorting files to find the most recent, to providing evidence in court. Each file (and directory) in APFS has four separate timestamps you can use:
Created, termed in APFS create_time, gives “the time that this record was created”.
Modified, mod_time, “the time that this record was last modified”.
Last opened, access_time, “the time that this record was last accessed”.
Attributes Modified, change_time, “the time that this record’s attributes were last modified”.
Although the Finder only displays those to the nearest second, the macOS API readily provides fractions of a second, commonly resolved to milliseconds, and the raw values are saved as nanoseconds since 00:00 UTC on 1 January 1970.
The first three are those most commonly used, although the last can be relevant in backups in particular. If you want to see which file in a folder is the oldest there, look for the oldest time Created. If you want to know which was most recently changed, look for the latest Modified time.
Where you must be careful is in interpreting those dates, as it’s easy to make assumptions that may not always work. The first confounding factor is that files can change without updating the Last opened time.
Apple’s APFS reference states that access_time is updated according to the behaviour set by that volume’s APFS_FEATURE_STRICTATIME setting. “If this flag is set, the access_time field of j_inode_val_t is updated every time the file is read. Otherwise, that field is updated when the file is read, but only if its value is prior to the timestamp stored in the mod_time field.”
Does APFS in macOS currently set the APFS_FEATURE_STRICTATIME for its volumes?
You can see how that works in a simple demonstration. Create a new text file in TextEdit and add a line or two of text to it, then save it. In the Finder, Created, Modified and Last opened timestamps will now all give the same time and date. Leaving that file open in TextEdit, wait a couple of minutes, then add another line to the file and save it again. In the Finder, the Modified time will be updated, but not the Last opened time, because the file hasn’t been opened and read again. Close the file, wait another couple of minutes, and open it again. You should see its Last opened time update, indicating that APFS_FEATURE_STRICTATIME is set for that volume.
My example is even more extreme. According to these timestamps, this file was Created on 13 July, and hasn’t been opened since. However, it was modified without being read on 23 September. If it’s opened and read now, it’s Last opened time will be updated whatever the APFS_FEATURE_STRICTATIME setting.
There’s another confounding factor that makes this even less reliable: QuickLook. Although its thumbnails and previews are constructed using file data, that access doesn’t affect either the Modified or Last opened timestamps, and opening and reading a QuickLook Preview isn’t recorded anywhere in a document’s attributes. So it could be extremely misleading to assume that a file hasn’t been viewed just because its Last opened timestamp hasn’t changed.
If you do want to use the timestamps on files or folders, it’s essential to know their limitations and behaviours, otherwise you could draw the wrong conclusions.
Apple has just released an additional out-of-cycle update to XProtect, bringing it to version 5321. As usual, it doesn’t release information about what security issues this update might add or change.
This version has no changes from 5320 in its Resources property lists or Yara file. Indeed, the version number given in XProtect.meta.plist remains 5320, although those given in the bundle’s Info.plist and version.plist are 5321.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5321
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5321 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
All of us at some time or other find our mind has gone blank and we can’t remember the password we’ve typed in so often before. Or the person who did know that password may no longer be there to recall it for us. At times like these we may need to gain access to a locked Mac. This article looks at how you can do that in an Intel Mac with a T2 chip, or an Apple silicon Mac, running Big Sur or later, in particular macOS Tahoe. If you want information for an older Mac or macOS, this article should be more helpful.
Keyboard
If you’re certain you entered the correct password but it was refused, check the Caps Lock key isn’t on, and check the Mac is using the correct language keyboard in the menu at the top right.
Firmware password (Intel only)
Intel Macs can be protected using a firmware password set and removed in Recovery, and that can normally only be removed if you know the password. If you don’t, the most reliable way to achieve this is to take the Mac to an Apple store, together with proof of purchase or ownership, and ask them to remove the firmware password.
Trying to guess a Mac’s password is doomed to failure: you only have ten attempts before you have to try in Recovery, and an absolute maximum of fifty attempts in total before access to its Data volume is permanently barred, and that Mac has to be restored in DFU mode. Time intervals are also added between attempts, starting at a minute after the third attempt, and rising to eight hours with the ninth.
Once you realise you don’t know the password, click on the ? to the right of the password entry box. If you keep trying to guess, your attempts will soon be delayed by lock periods that grow up to eight hours.
The Mac will then offer you the best option for resetting the password. If the Mac was opted into iCloud Recovery, you’ll then be asked for details of the Apple Account.
This is now handled by the Recovery Assistant, which also helps you use the Recovery Key if iCloud Recovery wasn’t chosen.
If you don’t have Apple Account details or the Recovery Key, the remaining option is to wipe the Mac. That’s offered in the Erase Mac command in Recovery Assistant’s menu.
For these the Mac needs an internet connection. Further details are in this support article. If you’ve forgotten your Apple Account password, Apple’s support article here should help.
Missing owner
Those methods all assume that you’re the owner/user, have simply forgotten your login password, and can recall your Apple Account details or Recovery Key. If the Mac belonged to someone who’s no longer there, and you don’t have access to their Apple Account, you won’t be able to use those options.
There are two further steps now available that you may find helpful. Provided your Apple Account has two-factor authentication enabled, if you’re unable to sign in or reset your password, you can ask Apple to perform account recovery. This isn’t immediate, but provided you can satisfy Apple that your request is genuine, it should prove possible.
As of macOS 12.1 and iOS/iPadOS 15.2, Apple has supported Legacy Contacts, but those must be set up before you need to use them. The Legacy Contact is then provided with an access key they can use in the event that you can’t because you’re dead. Apple also needs to see a copy of the death certificate before giving full access to the account for a period of three years. Full details are here.
Still no solution
If you want to access the Mac but not its contents, it’s straightforward to return Apple silicon and T2 models to factory condition by putting them into DFU mode and restoring them, as explained here. That may not always be a good step, though: when you try to set that Mac up again, it checks in with Apple. If it has been registered as stolen, you could find it becomes unusable.
If all else fails, get expert advice and help from Apple stores, authorised service providers, and from the many independent Mac technicians around the world who are often only too familiar with these problems.
Virtual machines
Depending on how they’re set up, macOS VMs can now support either iCloud Recovery, or a Recovery Key, provided the guest macOS can.
Apple has just released its weekly update to XProtect, bringing it to version 5320. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds a single new Yara rule for MACOS.SOMA.OCENB, another for the vast Soma/Amos family.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5320
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5320 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Apple has just released its weekly update to XProtect, bringing it to version 5319. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds three new Yara rules. MACOS.SOMA.OCENA is yet another for the vast Soma/Amos family, and there are two for the far newer MACOS.ODYSSEY group, MACOS.ODYSSEY.SOCGO and MACOS.ODYSSEY.SEENA.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5319
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5319 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
I hope that you enjoyed Saturday’s Mac Riddles, episode 329. Here are my solutions to them.
1: Two credentials or 762 should be superseded by passkeys.
Click for a solution
2FA
Two credentials (two-factor authentication uses two secrets, such as a password and a PIN code sent separately) or 762 (0x2FA in decimal) should be superseded by passkeys (a modern and more secure replacement).
2: Notably from Autodesk but once by Claris, it’s 3,245.
Click for a solution
CAD
Notably from Autodesk (vendors of AutoCAD and other computer-aided design software) but once by Claris (ClarisCAD, 1989-1991), it’s 3,245 (0xCAD in decimal).
3: From the Mac II until replaced by USB, 2,779 was quite enough.
Click for a solution
ADB
From the Mac II (Apple Desktop Bus, introduced as the peripheral interface for Mac II and SE) until replaced by USB (it was, with the iMac), 2,779 (0xADB in decimal) was quite enough (it didn’t support hot-swapping, which could result in electrical damage).
The common factor
Click for a solution
They are all hexadecimal numbers as well as abbreviations.
Apple has released its weekly update to XProtect, bringing it to version 5318. As usual, it doesn’t release information about what security issues this update might add or change.
This version makes several changes to the Yara definition for MACOS.COMPLIANTPIRATE.DEFU, but doesn’t add any new detection rules.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5318
Sequoia and Tahoe systems only
This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5318 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
However, if the regular update has been installed in the old location, XProtect is likely to update its new location from that. There’s nothing you can do to force that, but it may well explain why your Mac seems to have updated itself.
You’ve just run First Aid in Disk Utility, or fsck_apfs, and that reports warnings or errors. What should you do next?
Failure to unmount
By far the most frequent error encountered in Disk Utility’s checks results from its inability to unmount a volume before it can start testing. While this is reported as an error, and it prevents the checks from running, it can sometimes be solved by manually unmounting the volume in question. It normally doesn’t indicate anything sinister, and is simply frustrating.
Repeat in Recovery mode
If the warnings or errors were reported on your current boot Data volume and you ran that check in normal user mode, consider starting your Mac up in Recovery mode to repeat the check there.
Although macOS does an impressive job of performing checks on a live volume, it’s more reliable and more likely to be able to perform any repairs needed in Recovery mode, when the Data volume isn’t mounted and live. When there, if you prefer, you can still use fsck_apfs in Terminal.
The other case where checks may be best made in Recovery are those on an active Time Machine backup volume. That’s because those can be difficult to unmount before running the checks, although that is possible as long as a backup isn’t being made at the time, or Spotlight indexing taking place. The sure way to avoid those is to do so in Recovery mode.
Warnings or errors?
Any remarks about problems or irregularities encountered during checks should make explicit whether they are warnings or errors, and it’s essential to make a clear distinction between them.
Warnings are observations that could have significance, or might be perfectly normal in the circumstances. Only an APFS engineer is likely to be able to tell the difference. Among the commonest are those reporting missing xattrs for compressed files: warning: inode (id 113812826): Resource Fork xattr is missing for compressed file
Experience is that those aren’t related to any consequent errors, and you should be able to leave those alone.
Errors are abnormalities that do have more significance, and might have the potential to cause further problems. Where possible, First Aid or fsck_apfs should attempt to repair those, most probably by performing “deferred repairs”. Those are normally minor errors that it already has plans to attend to when that volume is next mounted, the time that APFS normally performs its routine maintenance.
Snapshots
These are read-only copies of the file system metadata at a previous instant in time, and are associated with retained storage blocks. They aren’t part of the active volume, and their metadata are separate. As they’re read-only, any warnings or errors are most unlikely to be fixed, so you have a choice of leaving that snapshot to be deleted routinely by age, or deleting it early yourself.
Snapshots are made by backup utilities including Time Machine, which are required by Apple to have a mechanism that will delete them automatically after a set period. In the case of Time Machine, that’s when the snapshot is over 24 hours old. Snapshots aren’t backups, but augment regular backups, and stand in for them when backup storage isn’t available. In general, there seems little point in deleting a snapshot early just because there’s a reported warning or error for it, as that won’t affect the health of the active volume.
Identifying faulty items
Warnings and errors related to specific files or directories are normally given with an item id, which should be their inode number. To go any further, you’ll need to convert that to a path and file/directory name. You should therefore copy and paste all reports into a separate file as reference. Resolving an inode to a path and item name is detailed in this article.
In many cases involving items that can be resolved to an existing path, the faulty item is in one of the hidden folders such as .Spotlight-V100 for Spotlight indexes, or .DocumentRevisions-V100 for the document version database. In the former, rebuilding Spotlight’s indexes may resolve the problem, but you’re unlikely to be able to do anything about the latter.
If the inode resolves to a regular file, deleting that can remove the problem, but when you try restoring that file from a backup you may discover the backup has the same problem. Getting to the bottom of a recurrent file system error might require the knowledge and skills of an Apple engineer. Consider reporting this using Feedback, as it should then help iron out any remaining bugs in APFS.
You should also consider whether your Mac might be running old third-party software that is causing recurrent errors. Normally, products should work at a higher level that isolates them from the file system itself, but there are some surprising exceptions. If you can identify a cause, please inform the developers of that software so that it can be fixed.
Old versions of APFS
One potentially dangerous practice occurs when an older version of APFS changes a newer file system. APFS back in High Sierra and Mojave knew nothing of boot volume groups, firmlinks, or many of the features of more modern versions of APFS. If you really must run different versions of macOS on the same Mac, or shared external storage, avoid such version conflicts, and never run an older version of Disk Utility or fsck_apfs on a newer APFS container or volume.
I hope that you enjoyed Saturday’s Mac Riddles, episode 328. Here are my solutions to them.
1:
Carlos Schwabe (1866–1926), Evening Bells (1891), watercolour, dimensions not known, Museu Nacional de Belas Artes (MNBA), Rio de Janeiro, Brazil. Wikimedia Commons.Click for a solution
Angels
Schwabe’s painting shows a chain of angels emerging from a belfry.
2:
Gustave Doré (1832–1883), The Demons Threaten Virgil (c 1857), engraving, dimensions and location not known. Image by Karl Hahn, via Wikimedia Commons.Click for a solution
Daemons
Doré’s engraving shows The Demons Threaten Virgil, from his illustrations to Dante’s Inferno.
3: James Bond, Jason Bourne, George Smiley, Modesty Blaise
Click for a solution
Agents
They are each (secret) agents: James Bond from Ian Fleming, Jason Bourne from Robert Ludlum, George Smiley from John le Carré, and Modesty Blaise from Peter O’Donnell.
The common factor
Click for a solution
They are each run by launchd from property lists in folders titled LaunchAngels (new in Tahoe), LaunchDaemons and LaunchAgents.
For many years, I believed what the log command told me, that log entries could contain any of the 26 or more fields available, although they didn’t. It was only as I was developing utilities like LogUI that I discovered that log entries come in (at least) four types, each with its own format and set of fields. This article is a guide to those, and how they are displayed in LogUI.
Entry fields
Those available in the OSLog API are fewer in number than appear in log command output, and include some of limited interest. Those not exposed in LogUI include:
store category, which is invariably disk storage here.
format string, that used to format the contents of messages. This was introduced following serious security leaks in High Sierra.
components, linking in with the format string.
LogUI displays each entry using the same order of fields and colour-coding. Although they can’t all be seen together in any single log entry, the overall sequence is:
Standard levels are given as text, and chosen from one of the following: fault, error, notice, info, debug, undefined. These are only used with Regular log entries, not other types. LogUI always includes debug level entries when they’re available.
The four types of entry are:
Regular
Activity
Boundary
Signpost.
Regular entries
These are normally by far the most common, and are seen throughout the processes and subsystems writing log entries. They normally contain up to the following fields:
datestamp, [1], activity ID, category, level, sender, process, process ID, subsystem, thread ID, message
These examples include:
datestamp, 1, activity ID, category, level, sender, process, process ID, subsystem, thread ID, message
which is fairly normal.
Activities
These mark specific activities, and vary according to the process and subsystem. Some are valuable waypoints, and all are recognisably shorter than most regular entries, containing only the following fields:
datestamp, [2], activity ID, parent activity ID, sender, process, process ID, thread ID, message
These are examples of one of the most valuable activities reported, indicating a mouse-click or tap. They’re also complete, as they consist of:
datestamp, 2, activity ID, parent activity ID, sender, process, process ID, thread ID, message
Boundaries
These are rare but instantly recognisable because of their brevity. They consist of just three fields:
datestamp,[3], message
Two of the most important are the announcement of the start of kernel boot:
and adjustment of the internal clock:
These are also easy to search for, as their message contains the distinctive === string.
Signposts
By default, LogUI extracts omit Signposts, but if you tick the Show Signposts box before loading log entries, they will also be displayed. In parts, they can outnumber regular entries, and are unlikely to provide you with meaningful information unless you know internal details of their process. Each Signpost adds three type-specific fields, shown after the process ID:
datestamp, [4], activity ID, category, sender, process, process ID, signpost ID, signpost name, signpost type, subsystem, thread ID
These examples come from the most prolific user of Signposts, SkyLight for WindowServer, and contain
datestamp, 4, activity ID, category, sender, process, process ID, signpost ID, signpost name, signpost type, subsystem, thread ID
Note there’s no message field, as their meaning is determined by the signpost fields.
Datestamps and times
The OSLog API doesn’t currently give access to Mach times, only to opaque Date variables. From those, LogUI’s datestamps give:
year–month–day hour:minute:second.microsecond+timezone
All times and time zones given are those current when LogUI obtains that extract, not when that entry was written. This can become extremely confusing when clocks change to and from {summer time, daylight time, daylight saving time, daylight savings time, DST}, and when passing through time zones, and great care is required when reading logs containing such corrections. LogUI tries to make this easier, but care is still required.
If you have used the log command, you may be aware that can return Mach times as ticks, offering precision down to the nanosecond. This currently isn’t possible when using the OSLog API, but given the relatively slow clock of Apple silicon Macs, it’s no longer as useful as it used to be with Intel’s nanosecond Mach ticks.
Censorship
By default, all data in message fields is censored to protect the privacy of the user. This replaces chunks of text with the dreaded <private>, and can render many entries devoid of any useful information. In recent versions of macOS log privacy can be removed by installing a profile. However, that doesn’t apply retrospectively, only to log entries collected after the profile has been installed.
Removing privacy also increases the size in storage of log entries, and may reveal sensitive information. As soon as you have completed acquisition of the logs you need with privacy removed, you should therefore remove the profile, to allow normal censorship to resume.
To install the profile, unzip the archive into a convenient folder and double-click it. You’ll be informed by a notification that you need to review the profile to install it. Open System Settings and select Device Management in its View menu, or search for it. Follow the instructions given there to install and activate it.
Sadly, this doesn’t cover all censorship. Some systems require additional configuration changes, for example CFNetwork diagnostic logging. Jeff Johnson explained how to enable that, but Apple has since blocked that, and I don’t know of a practical alternative. In some cases, additional detail can be obtained by adjusting log settings.
Summary
A short practical summary of LogUI’s log entries is provided in its Help book.
Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.
1:
Carlos Schwabe (1866–1926), Evening Bells (1891), watercolour, dimensions not known, Museu Nacional de Belas Artes (MNBA), Rio de Janeiro, Brazil. Wikimedia Commons.
2:
Gustave Doré (1832–1883), [title withheld] (c 1857), engraving, dimensions and location not known. Image by Karl Hahn, via Wikimedia Commons.
3: James Bond, Jason Bourne, George Smiley, Modesty Blaise.
To help you cross-check your solutions, or confuse you further, there’s a common factor between them.
I’ll post my solutions first thing on Monday morning.
Please don’t post your solutions as comments here: it spoils it for others.
Apple has released its weekly update to XProtect, bringing it to version 5317. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds five new detection signatures to its Yara file. These include another newcomer with four signatures, MACOS.DAILYDUMPLING, and MACOS.SOMA.SEEND to add to the large Amos/Soma family.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5317
I apologise for the late announcement of this update, which seems to have been released after 22:00 GMT on 30 September, but was still incomplete here through the whole of today, 1 October.
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5317 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
I hope that you enjoyed Saturday’s Mac Riddles, episode 327. Here are my solutions to them.
1: Lost rocket platform as an app for your apps.
Click for a solution
Launchpad
Lost (it has been removed from Tahoe) rocket platform (a launchpad) as an app for your apps (what it was, an app for launching other apps).
2: Burning telegraph and lynx now disconnected.
Click for a solution
FireWire
Burning (fire) telegraph (wire) and lynx (Texas Instruments’ name for FireWire, IEEE 1394) now disconnected (support has been dropped from Tahoe, although oddly its kernel extensions are still present).
3: Happy Christmas 2017 is sad September 2025 for the most powerful Mac.
Click for a solution
iMac Pro
Happy Christmas 2017 (although announced the previous June, it shipped in December 2017) is sad September 2025 (it’s one of the T2 models dropped from Tahoe) for the most powerful Mac (when introduced, it was described as “the most powerful Mac ever made”, at least until the Mac Pro 2019).
Login
