This week I have another group of four little utilities whose windows have been overhauled, and have new app icons to meet the requirements of macOS Tahoe. Each of these new versions requires macOS Big Sur or later.

Finder aliases

If you have old Finder aliases that need to be checked and repaired, Alifix will do that job with you. Use it to scan a folder containing those aliases, and it will warn you which can’t be resolved any longer, and can rewrite those that need to be updated.

Alifix version 1.4 is now available from here: alifix14
and from its Product Page. As it seldom needs updating, it doesn’t use the auto-update mechanism.

APFS sparse and clone files

As you can tell by its name, Sparsity started off as a means of creating APFS sparse files for test purposes. In addition to that, it has a valuable scanning feature that will detect and report details of all sparse, clone and purgeable files in a selected volume or folder. Information reported includes both the nominal and actual size of each file, so you can see which sparse files are saving the most space on disk.

Sparsity version 1.4 is now available from here: sparsity14
and from its Product Page. It too doesn’t use auto-update.

UTI file types

Give UTIutility a filename extension and it will tell you its Uniform Type Indicator (UTI, also UTType), traditional Mac OSType, MIME type, Pasteboard type, and a list of UTIs it conforms to. You can also find the same information from those other properties. This too has a crawler that will search through a volume or folder and compile a list of all the UTIs it encounters there. Its Help book contains an extensive reference to UTIs to help you get the most out of them.

UTIutility version 1.4 is now available from here: utiutil14
and from its Product Page. It doesn’t use auto-update.

Natural language

For many years, macOS has had built-in features to handle and parse natural languages including French, Spanish and German. Nalaprop uses these features to analyse text files, or text pasted into the left view in its main window. That text can then be parsed by downloadable linguistics modules supplied by Apple, and each word displayed in colour according to that word’s part of speech or grammatical type. From that it can automatically construct dictionaries or concordances of words used in that text, arranged by part of speech, and giving word frequency for each.

Nalaprop comes with a multilingual demonstration file to show how well it copes with language transitions.

Here it has parsed and coloured the text in the middle according to part of speech, for two languages, English and French. To the right of those is the dictionary it has compiled, ending verbs and starting the list of nouns. At the far right is a colour key for parts of speech.

In this demonstration, Charles Dickens’ novel David Copperfield has been parsed, a total of nearly 360,000 words. Currently such large documents are analysed in the main thread, so you’re likely to see a spinning beachball during parsing, but can still switch freely to other apps when that’s taking place. Those with Apple silicon Macs will see that analysis is performed in a single thread running on one P core, so all the other P cores remain free to run other tasks. I was hoping to use different threads for this, but it proved too complicated to incorporate in this particular version.

Nalaprop version 1.4 is now available from here: nalaprop14
from its Product Page, and via its auto-update mechanism.

Enjoy!

Here are the 21 icons for those of my apps so far ported to be compatible with Tahoe.

You don’t have to collect all in the series, though.

It’s no miracle that a 10 GB disk image can be shrunk down to a few MB of sparse file. This article explains how APFS works that magic, first on a normal read-write disk image, then in the disk image inside a Virtual Machine.

What is a sparse file?

In essence a sparse file is any file whose allocated storage is smaller than the nominal size of that file. In APFS, this imposes two requirements:

• the INODE_IS_SPARSE flag is set for that file’s inode,
• the sparse byte count is given in its extended field.

As a result, the total size of storage allocated to that file’s data in its file extents is smaller than the total required to store the file at its nominal size. This is because the file contains empty data that isn’t stored on disk, saving disk space. This becomes clearer when we consider how this works with regular read-write disk images.

How a disk image becomes sparse

To demonstrate how this works, create a read-write disk image, which APFS will then turn into a sparse file. For the sake of simplicity, I’ll ignore all overheads such as the file system in that disk image.

APFS uses 4 KB storage blocks on SSDs. Creating a 4 GB disk image using DropDMG or Disk Utility therefore uses one million blocks. For this example I number those starting from 0000 0001 in hexadecimal, rising to 000F 4240 at the end of that disk image file, a million blocks later.

Once that has been created, copy a 4 MB file into the disk then unmount it, and mount it again. When it’s mounted that second time, APFS Trims it, and marks all its storage blocks apart from those 4 MB as being unused. That leaves my file occupying blocks 0000 0001 to 0000 03E8, and 0000 03E9 to 000F 4240 unallocated. APFS therefore sets the disk image file’s INODE_IS_SPARSE flag to TRUE and writes the sparse byte count to its extended field: the disk image is now a sparse file.

Creating a VM disk image

Unlike that read-write disk image, a disk image used for a Virtual Machine (on Apple silicon, at least) is created a sparse file in the first instance, using code like
let diskFd = open(diskImagePath, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR)
var result = ftruncate(diskFd, sizeDisk)
result = close(diskFd)
(error handling omitted) where sizeDisk is the size in bytes. Similar can be achieved in Terminal using the command
dd if=/dev/zero of=Disk.img bs=1m count=0 seek=10240
where the number given for seek is the size in blocks.

Maintaining the VM disk image

A read-write disk image is mounted and Trimmed by APFS on the host Mac. That used for a VM is different, as it’s the guest OS that has the task of Trimming the disk image from inside, and that works just the same as when macOS is booted on a Mac.

Read the entries made in your Mac’s log by APFS during startup. Those appear early with the start of APFS, when the version is given:
33.263 apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.101.1, apfs-2332.101.1, 2025/04/11

A little later, APFS Space Manager (Spaceman) Trims the first partition/container with log entries like:
34.012 spaceman_scan_free_blocks:4106: disk1 scan took 0.002064 s, trims took 0.000443 s
34.012 spaceman_scan_free_blocks:4110: disk1 101104 blocks free in 47 extents, avg 2151.14
34.012 spaceman_scan_free_blocks:4119: disk1 101104 blocks trimmed in 47 extents (9 us/trim, 106094 trims/s)
34.012 spaceman_scan_free_blocks:4122: disk1 trim distribution 1:14 2+:18 4+:8 16+:2 64+:1 256+:4

A couple of seconds later it trims a second partition:
36.391 spaceman_scan_free_blocks:4106: disk3 scan took 1.749635 s, trims took 1.147491 s
36.391 spaceman_scan_free_blocks:4110: disk3 351308484 blocks free in 319729 extents, avg 1098.76
36.391 spaceman_scan_free_blocks:4119: disk3 351308484 blocks trimmed in 319729 extents (3 us/trim, 278633 trims/s)
36.391 spaceman_scan_free_blocks:4122: disk3 trim distribution 1:118376 2+:48105 4+:82602 16+:42698 64+:24673 256+:3275
36.391 spaceman_scan_free_blocks:4130: disk3 trims dropped: 10469 blocks 10469 extents, avg 1.00

The following matching entries are taken from a macOS VM as it boots on an Apple silicon Mac:
02.557 apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.101.1, apfs-2332.101.1, 2025/04/11

03.278 spaceman_scan_free_blocks:4106: disk2 scan took 0.001036 s, trims took 0.000770 s
03.278 spaceman_scan_free_blocks:4110: disk2 126731 blocks free in 15 extents, avg 8448.73
03.278 spaceman_scan_free_blocks:4119: disk2 126731 blocks trimmed in 15 extents (51 us/trim, 19480 trims/s)
03.278 spaceman_scan_free_blocks:4122: disk2 trim distribution 1:4 2+:4 4+:5 16+:0 64+:0 256+:2

03.570 spaceman_scan_free_blocks:4106: disk4 scan took 0.295283 s, trims took 0.285527 s
03.570 spaceman_scan_free_blocks:4110: disk4 19188027 blocks free in 9939 extents, avg 1930.57
03.570 spaceman_scan_free_blocks:4119: disk4 19188027 blocks trimmed in 9939 extents (28 us/trim, 34809 trims/s)
03.570 spaceman_scan_free_blocks:4122: disk4 trim distribution 1:6010 2+:1072 4+:1775 16+:700 64+:244 256+:138
03.570 spaceman_scan_free_blocks:4130: disk4 trims dropped: 4252 blocks 4252 extents, avg 1.00

Just as the Trims performed on the host free up unused blocks of storage on the boot disk, so those in the VM do the same for the VM disk image. To demonstrate how those maintain the VM disk image in sparse format, I wrote two files inside the VM when it was running. One was a plain 10 GB file taking 10 GB on disk, the other a 10 GB sparse file taking a few MB. I then closed the VM and measured its size on disk, opened it again, deleted those two files and closed it again. During this I also took screenshots to verify changes recorded by Disk Utility in the free space inside the VM.

Before writing the two test files, the VM’s disk image size on the host was 107 GB, and it took 23.98 GB on disk as a sparse file. When it contained the two test files, its size remained the same, and it took 34.01 GB on disk. After deleting the files inside the VM, the disk image’s size remained the same, but it only took 24.01 GB on disk, and internally the VM reported that it had returned to 78.9 GB of storage available, the same as it had started with.

As expected, when the VM Trimmed it freed up storage space no longer used by the deleted files, as a result of which the VM disk image required less space on disk.

How the magic works

• Read-write disk images are created as normal files. They’re Trimmed by APFS on each subsequent mount, and may then become sparse files when there’s sufficient unused space in them.
• VM disk images are created as sparse files. They’re Trimmed by APFS in the VM during each boot and on demand, maintaining their sparse format when they have sufficient unused space.