Quarantine extended attributes, xattrs named com.apple.quarantine, aren’t attached to all files downloaded to Macs. Although once described as a voluntary scheme, putting files into quarantine is determined by a set of rules. This article explains how those rules work in macOS 26 Tahoe.
The default rule for apps that don’t run in a sandbox is that all new files they create don’t have a quarantine xattr attached to them. This is simple to verify by creating a new file using an app that hasn’t been obtained from the App Store, and isn’t one of Apple’s. Although it’s likely to get a MACL xattr attached, no quarantine xattr should accompany that. The same should also apply to files created by sandboxed apps, including TextEdit.
Info.plist
Although some processes and apps may explicitly attach quarantine xattrs, for example in AirDrop, this is a behaviour normally delegated to macOS by a setting in the app’s Info.plist, LSFileQuarantineEnabled. When that’s set to true, all files created by that app should bear the xattr. You can verify that by inspecting the Info.plist file in apps that download items from the internet, such as Safari, where it’s normally listed immediately below the app’s LSApplicationCategoryType.
No changes can be made to the Info.plist in a signed app, as those would break its signature.
CoreTypes.bundle
If that setting in Info.plist is false, or it doesn’t appear in the Info.plist, then there are additional and overriding settings contained in Exceptions.plist in the CoreTypes bundle, at /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources. That long list contains five dictionaries:
Additions, which assigns a lot of app categories, sets Java version requirements, and determines default settings for quarantine on files created by apps.
AppNapOverrides, which sets App Nap behaviours.
HighResolutionOverrides, which overrides High Res options for apps.
LaunchOverrides, which can disable specific version ranges of apps from being launched; these prevent older apps from being run.
MergeDocumentTypes, which merges some document types such as doc and docx for specific apps.
Overrides, which can override other settings.
Included in the Additions dictionary you should find overriding settings for the popular BitTorrent client Transmission, reading: <key>org.m0k.transmission</key>
<dict>
<key>LSApplicationCategoryType</key>
<string>public-category.internet</string>
<key>LSFileQuarantineEnabled</key>
<true/>
</dict>
Referring to the app by its ID of org.m0k.transmission, the first of those assigns the app to an app category of public-category.internet, then sets the app to attach the quarantine xattr to all documents that it creates, including everything that it downloads.
Among the existing overrides in Tahoe, for example, are org.pythonmac.unspecified.BitTorrent and org.xlife.Xtorrent, to ensure that Transmission, Xtorrent and PythonMac BitTorrent clients should write quarantine xattrs to all their downloaded files. Although this Exceptions property list doesn’t cover every client, it should ensure that most do protect their downloads by attaching a quarantine xattr.
The CoreTypes bundle isn’t in the Signed System Volume of macOS, but is protected from change. Thus, there’s no way the user can alter which apps add the quarantine xattr to new files they create.
Mach-O binaries
I don’t know how this system works with command tools, which are single file executables. They can have an Info.plist embedded in the executable, but this is rare unless they need to be notarized. The most popular tool for downloading files from the internet must be curl, used in commands of the form curl [URL] -o [localfile]
to download the file named in the URL to a local file named localfile. It’s simple to demonstrate that the download then doesn’t have any quarantine xattr attached to it, and those don’t gain the xattr when extracted from archives either.
While this does offer the user a way to download files that don’t have any quarantine xattr attached, it’s also almost universally used for the same purpose by malicious software.
Summary
By default, apps don’t normally attach the quarantine xattr to files they create.
Most apps that can download files from the internet opt to attach the xattr by setting LSFileQuarantineEnabled to true in their Info.plist.
Some of those that don’t, have that overridden in the Additions dictionary of Exceptions.plist in CoreTypes.bundle.
One notable exemption is the command tool curl, which is also used by malware to escape quarantine.
Programs running in windowing environments, applications as we used to know them, have more complicated requirements than those run from a command line. Rather than embed all the resources they require for windows, menus and the rest in a single file, Mac OS broke new ground by putting those into resources stored in the app’s resource fork.
This is QuarkXPress version 4.11 from around 2000, with its resources displayed in the resource editor ResEdit. Executable code was also stored in CODE resources, and every file contained type and creator information to support the illusions created by the Finder.
Mac OS X
When Mac OS X was designed, it switched to the bundle structure inherited from NeXTSTEP. Instead of this multitude of resources, apps consisted of a hierarchy of directories containing files of executable code, and those with what had in Mac OS been supporting resources. Those app bundles came to adopt a standard form, shown below.
The bundle name has the extension .app, and contains a single directory Contents. Within that, the executable code is in the MacOS directory, which may contain both the main executable for the GUI app and any bundled command tools provided. Another directory contains Resources, including the app’s custom icon, and components of its GUI. In some apps, there’s another directory of Frameworks containing dylibs (libraries).
There are also two important files, Info.plist and PkgInfo. The latter contains the same type and creator information inherited from Classic Mac OS, and apparently isn’t mandatory although it appears universal. The information property list is essential, as it specifies the names of the executable and its icon file in Resources, the minimum version of macOS required, type declarations of the app’s documents, version numbers, and more.
When running a command tool in macOS, its Mach-O executable is launched by launchd, whose purpose is to run code. Launching an app is more demanding, although the app’s executable is still launched by launchd. Before that can happen, macOS starts the launch process using LaunchServices and RunningBoard, which rely on information obtained from Info.plist and other components in the app bundle.
macOS
This structure remained stable until the introduction of code signatures in Mac OS X 10.5 Leopard in 2007. Accommodating those added a directory named _CodeSignature containing the signature in a CodeResources file. That includes code directory hashes (CDHashes) to check the integrity of the contents of the app bundle. Apps distributed by the App Store include a store receipt in another directory, _MASReceipt. Since 2018, when Apple introduced notarization, the ‘ticket’ issued by Apple can be ‘stapled’ into the app bundle as the file CodeResources.
Many apps come with additional items that might in the past have been installed by them in their Library/Application Support folders and elsewhere, but are now included in the app bundle. These can include the following directories:
Library, containing folders of LaunchDaemons and LoginItems that would previously have been installed in either the main Library folder, or that in the user’s Home folder;
XPCServices, for executable code that the app uses to provide specific services;
Plugins, for some types of app extension (Appex);
Extensions, for other types of app extension, including app intents.
You may also come across other components, including a version.plist in Apple’s apps.
This centralisation of components in the app bundle has brought several benefits. Being self-contained, apps are easier to install and update, and cleaner to remove. Their components are less likely to go missing, and most of all they’re held within the protection of the app’s signature and notarisation, an important improvement in security.
Assembling these into a diagram shows how the anatomy of an app has grown over the last few years.
Components shown in pale yellow are either mandatory or essentially universal. Those shown in green are found in apps distributed through the App Store, while that shown in blue is the stapled notarisation ticket (optional). You will also see additional folders and components such as Automator workflows, scripts, and others.
There is no difference in structure between apps built for current Intel and Arm architectures. That’s because binaries in the MacOS folder (and executable code in other directories like Frameworks, XPCServices and Plugins) contain platform-specific code in a single Mach-O executable. Thus, an app that’s Universal and runs native on both architectures includes code for both in its single ‘fat’ code file, and they even have separate signatures stored within common files.
I hope that you enjoyed Saturday’s Mac Riddles, episode 336. Here are my solutions to them.
1: Interchange of wealthy words but not plain.
Click for a solution
rich text
Interchange (the format was intended for interchange of documents) of wealthy (rich) words (text) but not plain (not plain text).
2: Microsoft’s proprietary medical practitioner from 1983 until 2007.
Click for a solution
doc
Microsoft’s proprietary (although it has been reversed, it remains proprietary) medical practitioner (a doc) from 1983 until 2007 (although it has changed substantially over that period, it came with Word for MS-DOS in 1983, and was replaced by docx in Word 2007).
3: 2003-2007 = 1,050 afterword.
Click for a solution
WordML
2003-2007 (it was introduced in Microsoft Word 2003, and superseded by Office Open XML in Microsoft Word 2007) = 1,050 (ML in Roman numerals) afterword (after ‘Word’).
Cast your mind back to when you learned to drive, ride a bike, speak a foreign language, perform a tracheostomy, or acquire any other skill. Wasn’t confidence the key to your success? Whatever we do in life, confidence is always critical. If you run a business, one of the metrics that are likely to be collected is confidence in your business, as that’s such an important economic indicator. Confidence is every bit as important in computing.
Over the last few weeks I’ve been discovering problems that have been eroding confidence in macOS. From text files that simply won’t show up in Spotlight search, to Clock timers that are blank and don’t function, there’s one common feature: macOS encounters an error or fault, but doesn’t report that to the user, instead just burying it deep in the log.
When you can spare the time, the next step is to contact Apple Support, who seem equally puzzled. You’re eventually advised to reinstall macOS or, in the worst case, to wipe a fairly new Apple silicon Mac and restore it in DFU mode, but have no reason to believe that will stop the problem from recurring. You know that Apple Support doesn’t understand what’s going wrong, and despite the involvement of support engineers, they seem as perplexed as you.
One reason for this is that macOS so seldom reports errors, and when it does, it’s uninformative if not downright misleading. Here’s a small gallery of examples I’ve encountered over the last few years, to bring back unhappy memories.
Maybe you saved an important webpage in Safari 26.1 using its Web Archive format, then a couple of days later discovered you couldn’t open it. There’s no error message, just a blank window, so you try again with the same result. Another site shows the same problem, forcing you to conclude that it’s a bug in Safari. Are you now going to devote your time to obtaining sufficient information to report that to Apple using Feedback? Or to contact Apple Support and pursue its escalation to an engineer who might fortuitously discover the cause?
Silent failures like these are least likely to be reported to Apple. In most cases, we find ourselves a workaround, here to abandon Web Archives and switch to saving webpages as PDF instead. When someone else mentions they too have the same problem, we advise them that Web Archives are broken, and our loss of confidence spreads by contagion.
Honest and understandable error reporting is essential to confidence. It enables us to tackle problems rather than just giving up in frustration, assuming that it’s yet another feature we used to rely on that has succumbed in the rush to get the next version of macOS out of the door.
Eroding confidence is also a problem that the vendors of AI appear to have overlooked, or at least seriously underestimated. It’s all very well using the euphemism of hallucination to play down the severity of errors generated by LLMs. But those can only cause users to lose confidence, no matter how ‘intelligent’ you might think your AI is becoming. Go talk to the lawyers who have been caught out by courts submitting AI fabrications whether they still have full confidence in your product.
Yesterday I sang the praises of the little-known command tool textutil for converting text content between nine different formats. As I promised, today I offer a small wrapper app to make those conversions more convenient: Textovert.
textutil provides three features: general document information, text format conversion, and document concatenation. The first of those is probably best left to editors, and the last requires a document layout editor, so I chickened out of those for the time being. Textovert version 1.0 runs commands of the form textutil -convert format filename1 -output filename2
where format is the format of the output file, filename1 is the input, and filename2 the output file.
You select the output format from the nine options in the window’s dropdown menu, before dropping any files onto that window. If you want to perform multiple conversions at the same time, you can open two or more windows and set each to its own output format.
Then drag and drop files to be converted onto the window. This version of Textovert only accepts files (and document bundles like RTFD), not folders, as they present several problems I’d rather not go into just yet. Textovert will then work through all the files one at a time and prompt you to select a filename and location for the converted file to be saved. For those converting just one or a handful of files at a time, this gives you fine control.
For those who have just dropped a batch of dozens of files onto the window, Textovert’s default behaviour is to save the converted files in the same location as the originals, with the same filename but the new extension. Thus, converting ~/Documents/Project/Meeting.doc to RTF will default to saving that converted file as ~/Documents/Project/Meeting.rtf. If you’re happy with that, you can click your way through saving each document without checking further.
As each converted file is saved, Textovert writes a simple one-line report to its window, giving the original filename, to mark success, and the converted file’s extension. You can select and copy those from its window if you want to keep a record.
That screenshot was taken during testing, and shows two unsuccessful conversions, marked with a red exclamation mark. Hopefully you won’t encounter any of those.
You should be able to convert pretty well any file, although how much text will be recovered depends on textutil‘s skills, not mine. The app comes with its own short Help book, accessible through the Help menu, and provided separately as well. It requires a minimum of Sonoma 14.6 to support its SwiftUI interface.
I hope that you enjoyed Saturday’s Mac Riddles, episode 335. Here are my solutions to them.
1: Xeon and the first T2 made this the most costly of its line.
Click for a solution
iMac Pro
Xeon (it has an Intel Xeon W processor) and the first T2 (it was the first model to include the T2 chip) made this the most costly of its line (it remains the most expensive iMac).
2: The first laptop with Intel, M1 and M5, it has never quite reached 18 inches.
Click for a solution
MacBook Pro
The first laptop with Intel (Core Duo, 2006), M1 (2020, alongside MacBook Air) and M5 (2025), it has never quite reached 18 inches (the largest has been 17 inches).
3: Last incision went from KeyGrip to Women of Wrestling.
Click for a solution
Final Cut Pro
Last (final) incision (cut) went from KeyGrip (its original name, before it was bought by Apple from Macromedia) to Women of Wrestling (the first full broadcast quality widely distributed TV show produced using FCP, in 2000).
QuickLook makes it easy to preview most files, and TextEdit will display the text content of many formats. There are times, though, when it’s more convenient to extract the text content and save it in a different format, for example turning a Safari Web Archive or Word document into Rich Text. Thankfully, there’s a tool to do that in Terminal, textutil.
textutil is one of the older command tools, and was introduced in Mac OS X 10.4 Tiger twenty years ago. Despite that, it remains one of the most underused in modern macOS. It works by tapping into the macOS text system, using any of the following nine formats:
plain text (txt)
HTML (html)
Rich Text, RTF (rtf)
RTFD (rtfd)
Microsoft Word .doc and .docx (doc, docx)
Wordprocessing Markup Language, WordML (wordml)
OpenDocument Text, ODT (odt)
Safari Web Archive, webarchive (webarchive).
The name given in parentheses is that used in these commands.
The quality of format conversions is high, essentially the same as you’ll see in Apple’s apps. For example, here’s an original Word .doc file:
and here is a conversion to RTF using textutil:
If the original file contains embedded images or other non-textual content, though, those aren’t included in the output.
Display information
This is the simplest option, used as textutil -info filename
where filename is the path and file name.
This displays basic information about the file, including its word count, and any metadata.
Format conversion
This extracts the text content of a file in one of its supported formats, and writes that out in a different format, as in textutil -convert rtf filename
where filename is the path and file name. The output file will then have its extension replaced appropriately, for example textutil -convert rtf myfile.html
will create the file myfile.rtf containing a Rich Text representation of the HTML file myfile.html. If you want to create a different output file, use a command like textutil -convert rtf filename -output filename2.rtf
Only text content is written to the output file.
Joining files
textutil‘s other main feature is joining text-based files together to form a single file consisting of the input files concatenated together, as in textutil -cat rtf -output filename.rtf -- file1.rtf file2.rtf file3.rtf
concatenates the three files file1.rtf file2.rtf file3.rtf into the single file filename.rtf in Rich Text format. You can also include implicit conversions such as textutil -cat rtf -output filename.rtf -- file1.html file2.rtf file3.html
where the first and last parts of the single output file filename.rtf are converted to RTF before concatenation. Note the -- before the list of input files consists of two hyphen characters, not a dash.
Further options
Advanced options detailed in man textutil and textutil -help include:
change text encoding from the default of Unicode UTF-8,
change font and size,
exclude HTML elements,
specify metadata.
In macOS Tahoe you may also encounter warnings relating to font availability and substitution.
Erasing SSDs securely has been a longstanding problem that has been solved in Macs with T2 or Apple silicon chips, with the introduction of Erase All Content and Settings (EACAS) four years ago in macOS Monterey. This article explains how it works, what it does, and when you should use it.
Boot disk
While Intel Macs are simpler, the internal SSD of an Apple silicon Mac is divided into three APFS containers/partitions.
Intel Macs have the same Apple APFS container with the Boot Volume Group in it, but the other two containers are replaced by a single small EFI partition.
macOS manages and uses the first two containers, ISC and Recovery, and that containing the Boot Volume Group is the one we’re concerned with. That includes the System and Data volumes, the former being made into a read-only snapshot that’s mounted as the Signed System Volume and contains macOS. Everything you install as a user, including apps and your Home folder, is in the Data volume, which is encrypted automatically even if you don’t have FileVault turned on.
Data volume
As the Data volume is invariably encrypted, the best way to securely erase its entire contents is to destroy its encryption key. Provided that can be performed robustly, so the key can never be recovered, no one will be able to decrypt its contents. (There is an expectation that one day it might be possible to break the encryption using quantum computing, but that’s not something you should be concerned with at present.)
The encryption key used to encrypt the Data volume is itself encrypted, and forms part of the mechanism used by FileVault when that’s enabled. To ensure that those encryption keys don’t leave the Secure Enclave, they’re encrypted again, and the key that’s destroyed by EACAS is one of those. macOS also employs anti-replay techniques to ensure that previous keys can’t be reused.
Additional features
In addition to destroying the encryption key for the Data volume, EACAS performs other useful tasks. These include signing out of your Apple Account, including iCloud and iCloud Drive, destroying all fingerprints used for Touch ID, and turning off Location Sharing to disable Find My and Activation Lock.
Although I can’t find any official account of additional data being erased by EACAS, I believe that all LocalPolicy records stored in Apple silicon Macs are also destroyed. LocalPolicy authorises access to external bootable disks, so those who have configured an external disk to boot their Mac are likely to be required to re-authorise it before it will boot that Mac again.
What EACAS doesn’t do, though, is sign you out of third-party cloud or other services such as Adobe’s Creative Cloud, or deauthorise that Mac for Apple media such as Music. Neither will it do anything to your Mac’s SSV: that’s left intact, still running the same version of macOS.
How to use EACAS
Start EACAS from System Settings > General > Transfer or Reset > Erase All Content and Settings…. In older versions of macOS still using System Preferences, open them and it’s offered as a command in the app menu.
If you continue, you should see one final warning before the contents of the Data volume are blown away into the great bit-bucket in the sky.
What’s left of your Data volume, shown here in Recovery mode, is a mere 300 MB or so.
When to use EACAS
If you want to wipe your Mac’s Data volume so you can reinstall its user(s), EACAS is the simplest and quickest way to do that, and doesn’t require starting up in Recovery. Its additional features ensure that, when you install its new primary user, everything should work properly and you don’t end up with ghost Macs left over from the past.
It’s the method of choice when preparing your Mac for disposal, particularly if you’re passing it on to someone else, as it ensures that no one can recover any of the data stored in your Home folder, or anywhere else on its Data volume. Performing that manually requires you to work through a list of additional procedures, almost all of which are automatic in EACAS.
The only time when you’re likely to prefer a different method is when you want to erase both the Data and System volumes, perhaps to return to an older version of macOS. Although you can do that using Disk Utility in Recovery mode, that doesn’t install the matching firmware. If you really want to return to factory-fresh conditions, the best way is to put that Mac into DFU mode, then restore it from the IPSW image file for that version of macOS. Although that does require a second Mac, it’s quick and comprehensive.
One other caution: never use EACAS on a macOS VM, as it’s unlikely to recover. It makes more sense just to delete the whole VM and be done with it.
Summary
EACAS performs a secure erase of the Data volume, as well as some useful extras.
It’s the method of choice for preparing your Mac for disposal.
It’s also suitable for wiping user data before setting your Mac up afresh, using its existing macOS.
If you want to wipe the System volume as well, to reinstall macOS, restore from an IPSW in DFU mode.
Apple has just released its regular weekly update to XProtect, bringing it to version 5323. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds five new Yara rules in its TIMELYTURTLE series, for MACOS.TIMELYTURTLE.DYCASWOC, MACOS.TIMELYTURTLE.DYCASWOCB, MACOS.TIMELYTURTLE.LELINO, MACOS.TIMELYTURTLE.TRNO, MACOS.TIMELYTURTLE.DYHEOC, and a single new rule for MACOS.REALSTAR.VO, which appears to be a new genus of malware.
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-5323
Sequoia and Tahoe systems only
This update has at last 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 5323 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Update
As of 22:00 GMT on 11 November, the update to 5323 has reappeared for download to the traditional location via Software Update or SilentKnight, and is available through the iCloud connection for Sequoia and Tahoe.
I hope that you enjoyed Saturday’s Mac Riddles, episode 333. Here are my solutions to them.
1: Black leopard exposé of 2003 could fax.
Click for a solution
Mac OS X 10.3 Panther
Black leopard (a panther) exposé (Exposé was one of its new features) of 2003 (released 24 October 2003) could fax (it was the first Mac OS X to come with integrated support for faxing).
2: Officially a 750, it brought the fastest notebook in the world in 1997.
Click for a solution
G3
Officially a 750 (its proper name is the PowerPC 750), it brought the fastest notebook in the world (the PowerBook G3) in 1997 (first Macs with the G3 came in November 1997).
3: Came with a plus, bulging trash and SCSI.
Click for a solution
System 3
Came with a plus (it shipped with the Mac Plus in January 1986), bulging trash (it was the first version of Mac OS to show the Trash bulging when it had items inside it) and SCSI (it was the first version to support SCSI devices).
《真是对 Mac 祛魅了，买了快一年还是后悔了，发发牢骚》帖子评论区有提到 Windows 文件管理更好，能不能展开说说哪里更好？
回想一下，Windows 右键-新建文件 是一个比较方便的功能； Mac Finder 的分栏视图是我用过就再也回不去的特性。
可能是因为平时我也没有接触、用到过什么进阶的功能，希望大佬可以科普一下学习学习。
我就是不理解了，mac 作为一个单独的系统平台，为什么要搞这么多其他环境的依赖，是自己不会写不会封装吗？我在 windows 那边干干净净，想要啥环境自己从头配到尾，想装在哪就装在哪，想用哪个版本用哪个版本。你 mac 这搞得这一套 py2 ，那一套 py3 的，我自己还得再装一套自己想要的版本，恶不恶心啊。
这几天真的是被 mac 配环境搞破防了。这也许就是我这辈子唯一一台苹果电脑了吧。wow ！ only apple can do ！
Apple has just released an update to XProtect for all versions of macOS, bringing it to version 5322. At the same time there’s an update to XProtect Remediator for Catalina and later, bringing that to version 156. As usual, it doesn’t release information about what security issues these updates might add or change.
This version of XProtect adds one new rule to its main Yara file, for MACOS.TIMELYTURTLE.DYCAOC, and amends the existing rule for MACOS.SOMA.OCENA. It also adds a new XPScripts.yr file containing two rules using an osascript (AppleScript) interpreter, MACOS.OSASCRIPT.COTABR and MACOS.OSASCRIPT.COTAWA.
XProtect Remediator 156, which follows version 153, adds one new scanning module, XProtectRemediatorConductor. It will be interesting to see whether this refers to a new codename, or its role among other scanning modules.
The XProtect Behavioural or Bastion rules embedded in XProtect Remediator 156 amend Rule 22, but don’t add any further rules.
You can check whether these updates have 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 these as a named updates in SilentKnight, their labels are XProtectPlistConfigData_10_15-5322 and XProtectPayloads_10_15-156
Sequoia and Tahoe systems only
This XProtect update has finally 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 5322 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Update: the iCloud update was finally made available after 22:00 GMT on 5 November, over 24 hours after the release of this new version of XProtect.
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
Login
