One of the magic tricks that characterised the Mac was its association between documents and their apps. No longer did a user have to type in both the name of the app and the document they wanted it to edit. All they needed to do was double-click the document, and it magically opened in the right app.

In Classic Mac OS, that was accomplished by hidden Desktop databases and type and creator codes. For example, a text document might have the type TEXT and a creator code of ttxt. When you double-clicked on that, the Finder looked up which app had the creator code ttxt, which turned out to be the SimpleText editor, and opened that document using that app.

Although those ancient type and creator codes still live on today in modern macOS, they no longer fulfil that role. Instead, each file has what used to be a Uniform Type Indicator (UTI), now wrapped into a UTType, such as public.plain-text, normally determined by the extension to its name, .txt or .text. When you double-click on a file, LaunchServices looks up that UTType in its registry, discovers which app is set as the default to open documents of that type, then launches that app with an AppleEvent to open the document you picked.

Recognising that we often want to open a document using a different app rather than the default, the Finder’s contextual menu offers a list of suitable apps in its Open With command. That list is built and maintained by LaunchServices, and has changed in recent versions of macOS. Whereas those lists used to consist of apps installed in the traditional Application folders, LaunchServices now scours every accessible volume and folder using Spotlight’s indexes to build the biggest lists possible. If you happen to have an old copy of an app tucked away in a dusty corner, LaunchServices will find it and proudly display it alongside those in everyday use, like a game dog triumphantly presenting not one dead pheasant but every one from miles around.

For those with lean systems, this gives them the flexibility to open a large text document using BBEdit rather than TextEdit, or to select which image editor to use for a JPEG. But for those of us with lots of apps lurking in storage, the result is absurd and almost unusable. It’s bad enough working through the 33 apps that LaunchServices lists as PNG editors, but being offered 70 text editors is beyond a joke.

Unfortunately, there’s no lasting way to block unwanted apps from being added to the list LaunchServices builds for this Open With feature. You can gain temporary relief by excluding them from Spotlight search, but should you ever open the folder they’re in using the Finder, those are all added back. This also afflicts apps in folders shared with a Virtual Machine, where the list includes App Store apps that can’t even be run from within that VM.

There are, of course, alternatives. I could drag and drop the document from its Finder window towards the top of my 27-inch display to the app’s icon in the Dock at the foot, which is marginally less awkward than negotiating my way through that list of 70 apps.

But there are better solutions: why not empower me to determine which of those 70 apps should be offered in the Open With list? This is such a radical idea that it used to be possible with the lsregister command that has become progressively impotent, as LaunchServices has cast its net further in quest of more apps to flood me with. Or maybe use a little machine learning to include only those text editors I use most frequently to open documents? Apple could even brand that LaunchServices Intelligence, although that’s a little overstated.

I can’t help but think of what those magicians from forty years ago would have done, but I’m certain they wouldn’t have offered me that list of 70 apps to choose from.

It must be almost two years since I last demonstrated some magic tricks involving available and purgeable disk space. At that time, the amount of space involved was a mere 83.71 GB. Today I’m going to show you how I converted 228.16 GB of purgeable space into used space, recovering a lot of my files in the process.

Prior to my iMac Pro’s forced update to Sequoia 15.3.1, described here yesterday, its internal SSD had around 150-160 GB free, with no purgeable space at all. Immediately before installing that update, SoftwareUpdate reported that there was 160.57 GB available. When I had coaxed it back into life, now running 15.3.1, the foot of each Finder window told me there was now “393.72 GB available”. Imagine my surprise/shock/horror that about 240 GB of what had been on that SSD before it was updated had now vanished.

Recalling my previous experience, I selected Macintosh HD in the Finder, and opened the Get Info dialog. That confirmed the situation, stating

• Available 393.72 GB (228.16 GB purgeable)
• Used: 828,672,419,328 bytes (829.67 GB on disk)

A little arithmetic reveals that of the 393.72 GB “available”, only 165.56 GB was actually free at the time, the rest being “purgeable”. Together the truly free and that used “on disk” amounted to 995.23 GB. Adding the 16.16 GB used by other volumes, my Mac’s internal SSD had grown in capacity to 1.011 TB, which made that slightly traumatic update worthwhile after all.

Sadly, Disk Utility wasn’t so impressed. The figures it gave were very different indeed:

• Available: 165.56 GB (none purgeable)
• Used: 818.52 GB + 16.16 GB on other volumes = 834.68 GB
• One snapshot of 7.16 GB

for a total disk size of exactly 1 TB. The figures my own Mints gave were in accord with those from Disk Utility.

Although I much preferred the Finder’s figure of nearly 400 GB of “available” space, I realised that could only come at the cost of purging all that 228 GB of “purgeable” space. As that seemed to include many of my files, I thought it was time to work this week’s magic trick. I therefore restarted the Mac, and all of a sudden purgeable space had vanished, leaving me with only about 165 GB of free space after all.

To remind you of what I found nearly two years ago, after updating to macOS 13.3.1, the Finder found 83.71 GB “purgeable”, and my SSD had then grown to 1.08 TB in size.

That’s two major versions of macOS and almost two years apart, and the Finder still can’t come up with correct figures.

Adding your own custom icons to files and folders goes back a long way, to Classic Mac OS where it was widespread. With all the changes brought in recent versions of macOS, particularly Sequoia’s changes to Quick Look, this article explains how you can still replace standard icons with your own.

Add a custom icon

You can copy an icon already used by an app, file or folder on your Mac by selecting it and using the Finder’s Get Info command. In that dialog, select the small icon at the top left of the window, and copy it.

If you want to modify or design your own icons, a good graphics editor like GraphicConverter is fine. Work with a PNG image with a transparent background and dimensions of 1024 x 1024 pixels. When it’s ready, select all and copy it.

To add your custom icon to an app, file or folder, select it in the Finder, open the Get Info dialog, select its current icon at the top left, and paste in your replacement.

Where it doesn’t work

There are some items that you can’t add a custom icon to. Any app, file or folder in the Signed System Volume can’t be modified in any way, and those in folders where you don’t have write access won’t work either. If you really wanted to display one of those with a custom icon, the only way to do that is to create an alias, and paste your replacement icon into Get Info for that alias.

How it works

When you add a custom icon to a file, the icon is converted into a traditional resource of icns type, and written to an extended attribute of type com.apple.ResourceFork attached to that file. That xattr is the modern equivalent of the old resource fork used in Classic Mac OS. It’s also surprisingly large, typically around 330 KB, which can bring its own problems as described later.

When you add a custom icon to a folder, including one that’s enclosing a bundle like an app or RTFD document, it isn’t added as an extended attribute to the folder, but is added to a hidden file named Icon? (the last character isn’t really a ? but is actually Carriage Return, UTF-8 0D) inside that folder. Normally, icons to be displayed for an app are saved as an AppIcon.icns file inside the Resources folder within the app bundle, but modifying that could break the app’s signature. A custom icon dodges that by being saved outside the bundle itself, and in an extended attribute rather than as data.

Aliases are complicated

Add a custom icon to a folder, then make a Finder alias to it. What you’ll then see is a muddle.

In the Get Info dialog, the Preview shows the custom icon, but the icon displayed in the Finder is the default folder with an alias arrow superimposed. To get the alias to display your custom icon, you have to Get Info on the alias and paste that icon into the top left.

This rule, that the Preview shows the icon associated with the original, while the regular icon shown is that for the alias itself, extends to bundled apps. As you can’t add a custom icon to a bundled app, because its bundle can’t be changed in any way, one workaround might be to create an alias to the app and add your custom icon to that alias.

What then happens is that your alias displays its custom icon, but the Preview shown is the original app icon that you can’t change.

The biggest problem with attaching custom icons to aliases comes when the alias needs to be remade, for example by my app Alisma. The remade alias is then likely to lose its custom icon, which you’ll have to paste in again.

iCloud folders are complicated too

Just when you think you’ve understood how custom icons work, you try using them in iCloud Drive, and discover that there are some further subtleties.

iCloud Drive doesn’t like storing Icon? files in the cloud, and even if it would do so, it couldn’t upload the crucial com.apple.ResourceFork extended attribute, as iCloud doesn’t like them. Furthermore, the standard custom folder icons that you see in iCloud Drive aren’t created by the same mechanism, and can’t be overruled by your own icons.

The end result is that, while you can add custom icons to plain folders in iCloud Drive, the only client that will see them is the Mac that customised them in the first place, as that’s the one with the Icon? file and its extended attribute. Other Macs and devices won’t see the custom icon, unless of course you add it to the same folder on them. The same goes for custom icons on files.

In the recent past, custom icons have been unreliable in iCloud Drive. That was because, when the folder was evicted from local storage, the hidden Icon? file was sometimes lost, and couldn’t be replaced when the contents of the folder were downloaded again. That appears to have been fixed recently, and they should now be more stable in macOS Sequoia.

Happy customising!

Do you occasionally double-click on a folder in a Finder column view, expecting it to open that folder in a new window? If so, somewhere deep in your neurones are a few that still remember how the Finder worked in Classic Mac OS, quite differently to that in modern macOS. This article traces its history.

In the original Macintosh human interface, the Finder was its centre, the scene of all interactions between the user and the computer, apart from applications. There were no diversions like a Dock, and little by way of ornament.

Even when it had gained colour with the Macintosh II and Colour QuickDraw, the Finder in Classic Mac OS was a clean and spartan environment, with no toolbar, no traffic lights, just basic controls. At the top left is the close button, and the drag resizer is at the bottom right. But its biggest difference from today’s Finder was that double-clicking a folder within a window opened that folder in a new Finder window, according to its underlying spatial metaphor, hence its name. If you double-clicked with the Option key held, the previous window was automatically closed as the new window opened on top.

Thus, each Finder window could only show the contents of a single folder, and that location couldn’t be changed within that window. Navigating from one folder to another was accomplished by opening windows. It wasn’t uncommon to end up with stacks of half a dozen or more, each displaying the contents of a different folder, and Steve Jobs once unjustly criticised this as turning the user into a window janitor.

Note in this screenshot from 1999, showing Mac OS 9.0, the printer and disk icons on the upper right of the Desktop, and the Trash can at the bottom right. There was no Dock until Mac OS X inherited it from NeXTSTEP.

Here’s another example, this time from 2001. The upper window here shows the top level of a bootable disk, Scratch1, with its custom System Folder icon containing the bootable System for Mac OS 9.1.

Mac OS X 10.0 Cheetah brought with it the distinctive blue-and-white Aqua look, traffic lights at the top left, and the first toolbar. This view shows its tools being edited, and how its special folders and locations including iDisk, a precursor to iCloud, were arranged in the toolbar rather than any sidebar. This replaced the Classic spatial metaphor with an interface more akin to a browser, a move that proved unpopular with some.

By Mac OS X 10.3 Panther, the sidebar was added. The original Aqua style is here being progressively replaced by brushed metal, and it worked more like NeXTSTEP than Classic Mac OS. Two of its three view types are shown here: Icon and Column views, the third being List view, and those remain today, with the addition of what was originally Cover Flow and became Gallery view after Mojave.

Optical disks added tools for ejection, and to burn writable media from the Finder’s toolbar. The Finder’s Preferences were starting to offer subtle customisations including ‘spring-loading’ using drag-and-drop.

In 2007, Mac OS X Leopard introduced bespoke icons for certain document types, such as images, with a thumbnail preview. Categories offered in the sidebar included Devices such as disks, Places for popular folders, and quick access to some Spotlight search categories.

These are the toolbar options for OS X 10.11 El Capitan from 2016, still with support for optical disk burning, to which are added Finder Tags (also a category in the sidebar) and the new Share tool.

The Finder also has the privilege of featuring one of the oldest obvious bugs in macOS, affecting the width of column views, as demonstrated below in macOS 10.15 Catalina of 2019, and still present in Sequoia.

The Finder underwent its last major redesign in macOS 11 Big Sur, when all traces of brushed metal were removed, icons were changed, and every corner became rounded. It’s a far cry from the original spatial metaphor.

Reference

Wikipedia on changing style in the Aqua interface style.

It always happens when you’re in a rush to eject an external disk, or when you’re trying to run First Aid in Disk Utility: you’re told that a volume or disk can’t be unmounted or ejected because “one or more programs may be using it” or similar excuses. Not that macOS gives you the slightest idea as to which programs are. This article looks at what you can do next.

Whatever you do, don’t just pull the cable of an external disk: not only will your Mac complain, but you could end up damaging the contents of its files, or even the file system on that volume.

Force eject

This is often offered as an option in the dialog, and if it’s available it’s worth trying if you don’t have the time to carry out a more orderly unmounting. macOS should then identify the processes that are accessing the disk, and terminate their access. That can take time, and seldom appears successful even if you allow a minute or two for it to complete. However, when it does work, it’s likely to be the simplest solution.

Try again

In Disk Utility, this is usually the best option, and if necessary you can try several times. You should also double-check that you’re trying the correct volume: if it’s one of the current boot volume group, System or Data, then you’re better off running First Aid in Recovery mode anyway.

Getting nowhere

When all else fails, the next step is to identify what’s using files on that volume or disk, so you can decide whether to force quit that process in Activity Monitor. Don’t do that blindly, as you could end up killing processes that your Mac does need to run.

To discover which files are open on any volume, use the command
sudo lsof /Volumes/myVol
where myVol is the name of the volume. If you’re unsure how to enter a volume name containing a space, locate it in the Finder’s listing for your Mac, and drag and drop that into Terminal. Once you’ve entered that, type your admin user password at the prompt, and you’ll see a list with entries like
mds 367 root 33r DIR 1,28 192 2 /Volumes/External2
mds 367 root 35u REG 1,28 0 87 /Volumes/External2/.Spotlight-V100/Store-V2/3DD5246F-9AEA-4F0E-9A53-AA63783C3C70/journalExclusion
which are the files and directories open on that volume. This needs to be run using sudo, as otherwise you won’t see any files that are opened by processes running as root, which are most often the culprits. Some recommend using grep, but that shouldn’t be necessary, as lsof is capable of its own filtering.

The information given about each open file contains, from the left:

• an abbreviated name of the command associated, here mds, the Spotlight metadata server;
• the open mode, as the single character following two digits, e.g. 33r is opened for read access only, while 35u is opened for read and write access;
• the type, DIR meaning directory, and REG meaning a regular file;
• the full path to the file or directory.

If you’d rather use an app, then my personal favourite is Sloth from here. Although it’s not notarized, it does everything that I’d want in terms of matching lsof or fuser‘s features. Most importantly, if you click its padlock at the lower right and authenticate, it will show all processes running as root.

If your Mac is running Sequoia, getting Sloth through its security checks is a bit of pain (and intentionally so). You can do this the ‘official way’ by downloading the app, unZipping it, and moving it into your Applications folder. When you try to run it, that will be denied and you’ll end up having to give it your individual authorisation in Privacy & Security settings. Alternatively, you can run the risk and cheat by stripping the com.apple.quarantine extended attribute from its Zip file first, so it doesn’t undergo full first run checks. Although that may be simpler, it also forces you to place complete trust in the app you’ve downloaded.

Once you know which processes are accessing files on that volume, you can decide whether to open the listing in one of Activity Monitor’s views, such as CPU or Disk, select that process, and click on the Stop tool to kill it.