Now that High Sierra has had a couple of updates, the first being ‘supplemental’, the second to 10.13.1, I wondered if APFS might be ready for use, albeit on SSDs only. This article looks at how complete its new features are, their usability and impact.

Clones

In addition to supporting aliases and soft links (but not hard links), APFS saves storage space by letting you make clones. You can thus have two different files (as they appear) for which the file system points to the same data. Unlike aliases, though, you can then change the ‘files’ independently of one another. These are ideal for versioning systems, as only changed data has to be saved.

The snag with the current implementation is that there seems to be no way for a user to tell whether a file is a clone or not. If you Option-drag to copy a file from one folder to another, on the same APFS volume, the Finder and ls -laO command show each file as taking the full amount of space, and do not report that they are clones.

Performing an Option-drag copy does, though, result in instant copying, regardless of file size, so does appear to make a clone rather than a traditional copy when it can.

Using the cp command in Terminal will create full copies, unless you use its -c option, in which case it will make a clone instead, if it can. This is minimally documented in the new man cp, but not mentioned in the Tools and APIs chapter of Apple’s APFS Guide. Thus, if you want an existing script to make clones rather than copies, you must change it to use the -c option. This ensures consistency of behaviour with cp on other file systems.

In theory, you shouldn’t need to know whether any given file is a clone or a true copy, but in practice this brings dangers for storage management. Imagine that you are getting a bit low in free space on a drive, and you’re working with a 50 GB movie, either as a straight clone or in a versioning system based on cloning. If you make some changes to it, they could amount to only a few megabytes of required disk space, or the whole clone could need to be written afresh, swallowing up most of 50 MB.

The Finder’s approach to this problem seems to be deliberately pessimistic, in assuming that each clone occupies the full space of the original. If you trust the Finder’s figures, you will therefore never use the space saved by this feature in APFS.

Cloning will probably work best when storage is managed automatically, without having to consider such psychological issues. Even then, not knowing whether files share common data storage looks like it could let users get into trouble, unless they keep plenty of free space. I’m sure that this isn’t the last that we’ll hear of this.

Snapshots

A snapshot is a saved read-only copy of the file system at a given moment, which is an excellent means of letting you revert to that previous state. Because it contains file system metadata, not backup copies of files, it takes very little space, and is made almost instantly.

The good news is that, as of High Sierra 10.13.1, snapshots appear to work fully, and are the mechanism by which Mobile Time Machine now makes its local ‘backups’. Apple doesn’t appear to have worked out quite how to present this feature to the user, though. If you’re not running Time Machine, the only way I could find of making a snapshot is with the command
tmutil localsnapshot
Perhaps I have missed something, though.

To view the list of snapshots available locally, use
tmutil listlocalsnapshots /
and you should also be able to restore from one using tmutil restore.

I was delighted to see that the macOS 10.13.1 updater made a snapshot immediately prior to installing its update, which is very encouraging. Even more positive is the fact that the Time Machine app recognises these snapshots, and lets you restore from them.

Rich Trouton at Der Flounder has also noted the snapshot made prior to this update, and explains that this is a new automatic feature of Apple software updates which require a restart. He shows how you can restart in Recovery mode and restore to that snapshot, in the event that such an install goes wrong. This is an important step forward in macOS.

Other Features

Space sharing between volumes in an APFS container seems to work well, although again there are issues over the psychology of storage management to consider. Encryption is well-supported, and as of 10.13.1 supports a recovery keychain file for unlocking. Sparse file storage will probably not see significant use until apps support it: you can’t, for example, expect the file system to spot an uncompressed TIFF file which might benefit.

But Finally

Apple has made Finder’s simple human interface progressively more complex. Originally:

• Dragging an item from one folder to another on the same volume moved it; to copy you Option-dragged.
• Dragging an item from one volume to another copied it.

Children of all ages, myself included, have found those principles clean and simple, and quite fail-safe.

Now, rules have become:

• Dragging an item from one folder to another on the same volume moves it.
• To make a copy (not clone) on an HFS+ volume, Option-drag to another location.
• To make a clone (not copy) on an APFS volume, Option-drag to another location, but I can’t see how to make a true copy.
• Dragging an item from one volume to another copies it, unless either of the volumes is on iCloud Drive, in which case it moves it.
• To make a copy (not clone) to or from iCloud Drive, use Option-drag instead.

I think most expert users are going to find themselves making errors at times.

(Thanks to @cahuk for arousing my interest.)