From HFS+ to APFS

Mon, 08 Jun 2026 06:00:00 +0000

For years I have had two external drives always connected to my home Mac Mini M1.¹ The first is a 2 TB external SSD containing all my work and personal documents, the code for the scripts and applications I develop, documentation, and so on.

A second mechanical drive keeps all my photos and music, as well as a large software library, mainly for macOS and Linux, which I started archiving more than twenty years ago, when you couldn’t find everything online, and which I still keep updating today.

This setup is necessary because the internal 1 TB drive is too small for my needs. But it also proves very useful every time I move to a new Mac: once macOS is configured and the essential applications are installed, I just need to connect the two external drives to be ready to work.

– Source: William Warby on Unsplash.

In terms of speed I don’t notice any significant difference between the internal drive and the external SSD. This is partly because the tasks I usually carry out, mainly writing and developing software, are not affected by the read or write speed of the drive. Even the media files on the mechanical drive aren’t an issue; when using Photos and Music I can surely afford to lose a few extra seconds.

Until macOS Monterey, displaying the contents of external drives was always almost instantaneous, even when dealing with folders containing thousands and thousands of files.

With Sonoma, suddenly everything changed. Every time I opened a folder containing a large number of files or subfolders, I had to wait several tens of seconds before being able to see the contents. Sequoia improved this behaviour sligthly, but only temporarily, as its latest releases have made opening folders on external drives as slow as before.

This slowness is not due to a hardware problem; the same drive connected to a Mac running Monterey displays files almost instantly. The problem lies in the software, or more precisely in how macOS manages the two main filesystems of the Mac world, HFS+ and APFS.

APFS

In 2017, after nearly twenty years of HFS+, Apple introduced a new filesystem optimised for solid-state storage devices, unimaginatively named Apple File System (APFS).

Up until Monterey the two filesystems coexisted peacefully: APFS had become mandatory for the system drive (that is, the one from which the Mac boots and which contains the operating system and applications), but nothing prevented you from continuing to use HFS+ for external drives, which in this way remained readable on older Macs and, with some effort, on Linux and Windows as well.

Starting with Sonoma (perhaps even from Ventura, which I always avoided using), access to the contents of folders on HFS+ drives became extremely slow. I don’t think Apple did this intentionally, perhaps to force users to switch to APFS. It is more likely that it was a simple bug that has never been fixed because Apple is no longer interested in supporting HFS+. In fact, the slowdown only affects the display of files in Finder, while opening or saving them is not affected.²

Due to laziness, I tolerated these slowdowns for two years. In the meantime, I replaced the 2 TB mechanical external drive with an NVMe SSD,³ but the speed at which folders opened improved much less than I would have expected.

So, a few days ago, I decided to take the plunge and convert both my external drives to APFS.

From HFS+ to APFS

With Disk Utility, switching from HFS+ to APFS is very straightforward: just right-click on the drive you want to modify and select Convert to APFS....

Before starting, it is useful to select the Show All Devices item from the View menu (or by clicking the View icon in the Disk Utility toolbar), so you can see how the structure of the drive changes as you switch from HFS+ to APFS.

In theory, the conversion process should not damage the files on the drive. However, it is better not to take risks and make a backup first. I write this from experience, as you will read shortly.

I had no problems with the first drive, the 2 TB SSD, perhaps because it was relatively empty with only 500 GB of the total 2 TB used. Converting from HFS+ to APFS took only a handful of seconds, after which the drive finally became fast and responsive, as expected of an SSD.

You can read but not write

The conversion of the mechanical drive was an entirely different matter. This drive, unlike the previous one, has only 500 GB free out of 2,000 total. But 500 GB is still a quarter of the total capacity and so, after the positive experience I had just had, I decided to start without making a backup, as the files it contained could always be restored from Time Machine.

When it went to convert the drive to APFS, Disk Utility started grinding away for quite a while; maybe it was only a minute or two, but a minute can feel like an eternity when you’re doing something like this. After that, Disk Utility stopped and warned me that the conversion process had failed.

Luckily, despite the error, the drive continued to work as usual. For that, I would like to thank the Apple developers, who did an excellent job of ensuring that the file system conversion – an extremely delicate process that modifies the underlying structure of the drive – could fail without damaging the files stored on it.

Needless to say, I tried again with the same result.

ABefore trying again, I decided it would be wiser to make a backup of everything onto another external hard drive first. This took the whole night, but it was better not to take too many risks.

It must have been a premonition, because on the third attempt Disk Utility gave up and reported an error -69860, “The underlying task reported failure on exit”, which was so vague as to be meaningless. However the consequence was clear: that the drive had become read-only. I could read all the files without any issue, but I could no longer write a single bit.

Since I had a fresh backup on hand, I didn’t panic too much. Using Disk Utility, I erased the entire drive, this time choosing APFS as the filesystem. To do this, simply select the drive and then click the Erase button in the Disk Utility toolbar.

Restoring the files

The next step was to restore the files from the backup. First, I tried using the Finder to manually drag each folder from the backup drive to the newly reformatted APFS drive.

There were no problems with folders containing relatively few files, but when it came to a much larger one, the Finder eventually gave up, claiming that the drive already contained a file with the same name. The file obviously wasn’t there because I was rebuilding the drive from scratch, but I didn’t want to waste any more time investigating, only to end up with the same error an hour later.

So, I opened the good old Terminal, moved with cd into the root folder of the drive to be restored (which I’ll call Media HD here),

% cd "/Volumes/Media HD"

and copied the folders one by one from the backup drive (Backup HD) to the destination drive. Before doing all this I reformatted again Media HD to start from a clean state.

% cp -p -R "/Volumes/Backup HD/<directory A>" .
% cp -p -R "/Volumes/Backup HD/<directory B>" .
...

Here, <directory A>, <directory B> (without the trailing /) and so on refer to the names of the folders (or directories) to be copied. The -p option specifies that the copy should not modify the file attributes,⁴ while -R means that all files and folders being restored should be copied recursively. Please note that the . at the end of each command is mandatory, as it specifies that the files must be copied into the current folder of the destination drive.

The great thing about using Terminal is that once you have started the copy process, you can set it aside and let it work while you do other things. Just make sure you don’t close Terminal or touch the backup or destination drives.

The downside is that you have no idea what is happening or how many files have been already copied. Using the -v option is out of the question, because it would cause cp to print the name and path of every copied file, slowing down the whole operation.

It is much better to open a second Terminal tab and navigate to the root folder of the drive being restored (if it doesn’t already appear automatically) with

% cd "/Volumes/Media HD"

and then run the command

% du -h -d 1 "/Volumes/Media\ HD/<directory A>"

which returns the list of folders contained in <directory A>, together with their respective sizes. The total size occupied by <directory A> is shown at the end. By comparing this with the size of the folder on the backup drive it is easy to get an idea of how much is left to copy.

One word of warning: when cp is busy copying a large file, du can be very slow to respond. Be patient and don’t worry, these are Unix tools, reliable stuff that crashes pnly when you hit them with a hammer!

Even the Terminal can act up

Although the Terminal is usually more reliable than the graphical interface, there are rare cases where it can cause problems.

It happened to me with a folder of about ten gigabytes, containing an enormous number of very small files arranged in deeply nested folders, which has always been difficult to transfer from one drive to another. Usually, the best thing to do is to compress the folder from the Terminal,

% tar -czf large_folder_with_many_files.tar.gz "Volumes/Media HD/Large folder with many files"

transfer it to the other drive and then expand again it with

% tar -xzf large_folder_with_many_files.tar.gz

I’ve done it many times before and it has always worked. This time, however, it didn’t. When I tried to decompress the file, a “Special header too large error” appeared, which could be related to some weird modification to the folder or its files that occurred while I was trying to convert the drive to APFS.

The problem here was that I could have all the backups in the world, but if I couldn’t decompress the file, I would have ended up restoring the folder from Time Machine, which would have taken an inordinate number of hours.

Luckily, on my Mac I always have a few utilities that I might rarely use, but that turn out to be essential when I need them. That’s the case with The Unarchiver by MacPaw, which is available on the App Store. Don’t ask me how or why, but The Unarchiver managed to unpack the tar.gz file without a hitch, and it did so very quickly, too, perhaps even faster than the usual tar command in the Terminal.

Conclusions

In the end, everything worked out fine, and I managed to convert my two external drives from HFS+ to APFS without losing a single bit of data and in less time than I would have expected.

Access to the drives is now lightning-fast again, just as it was in Monterey and earlier versions of macOS. I still don’t understand what happened inside macOS to make drives formatted with HFS+ so inefficient. I don’t think Apple did it on purpose to push users towards the new filesystem. It is far more likely to be a bug that Apple is no longer interested in fixing.

While my personal experience of converting from HFS+ to APFS is statistically insignificant, I believe it is reasonable to conclude that the conversion process should not cause any problems provided the disk is relatively empty (i.e. up to 50% full). I haven’t been gazing into a crystal ball; the reason is simply that, under these conditions, macOS should have ample space to create the data structures of the new file system without touching the existing ones.

Above that threshold the conversion might work or, as happened to me, it might throw errors. In that case it is better to play it safe and make a preventive backup rather than risk losing your documents or getting stuck in arcane repair processes that you never know how (or when) will end.

Many users love to live on the edge and consider backups to be a waste of time. However, backups are never a waste of time, they are insurance for your data. And, unlike regular insurance policies, they are free or almost so.

In any case, never panic if something unexpected happens. It’s better to take a break, think it over, and look up information online, because reacting (badly) on instinct can do more damage than has already been done.

There is also a third drive dedicated exclusively to Time Machine. But that drive is indispensable and doesn’t count. ↩︎
If you want to force someone to do something, it is better to do it properly, isn’t it? ↩︎
I was lucky to choose the right moment. Today, the same drive would cost more than twice as much, and it might not even be easy to find. ↩︎
File attributes are the metadata associated with a file that define its behaviour and access modes. These include the file’s creation and modification dates, read and write permissions, file ownership, and so on. ↩︎

Filesystem on Melabit

From HFS+ to APFS

APFS

From HFS+ to APFS

You can read but not write

Restoring the files

Even the Terminal can act up

Conclusions