As promised, Sierra 10.12.6 addresses the previous problems with Apple’s new file system, APFS, by making it normalising, thus compatible with HFS+ file and folder naming.

Unfortunately, the update also breaks the tools provided in 10.12.4 and 10.12.5 for working with APFS, and Disk Utility is similarly incapable of even distinguishing between case-sensitive and case-insensitive variants of APFS. While 10.12.6 does read from and write to APFS volumes, it can do little more than that.

Disk Utility

For some time after the release of High Sierra, there will be many Mac users who have and work in mixed environments, in which some systems will still be running Sierra, and some will have been upgraded to High Sierra. Let’s say that you work during the day on a High Sierra system, and bring an external disk away to work on another Mac still running Sierra.

If that external drive uses APFS, you will be unable to check or repair it, only read or write to it, when you connect it to a Mac running Sierra 10.12.6 or earlier. Disk Utility only vaguely recognises APFS, and incorrectly reports all its volumes as being case-sensitive. You’d be a fool to use APFS on removable storage which might go near a Mac running anything other than High Sierra. You’d also be playing with fire to mount a High Sierra system in Target mode with a Mac running Sierra.

Command tools

When basic tools like Disk Utility let you down, you’re normally better off going to Terminal’s command line to solve your problem. In this case, the problem gets no better.

Back in early April, I detailed how to make your own APFS volume, ready for use with Sierra. That process works fine in 10.12.4 and 10.12.5, but has broken in 10.12.6.

In essence, you create a newly-formatted HFS+ drive with a single volume, then convert that to APFS using a command like
apfs_hfs_convert -v -i /dev/disk4s3
You then unmount the single volume, and create an APFS container with
diskutil apfs createContainer disk4s3
Once that is ready, creating a volume runs something like
diskutil apfs addVolume disk5 'Case-insensitive APFS' Fixed
when the container is mounted at disk5.

In 10.12.6, Apple has stripped all the most useful verbs from diskutil apfs, and it no longer supports the creation of containers or addition of volumes. The only verbs now supported by diskutil apfs are list, deleteContainer, deleteVolume, and unlockVolume. Instead, you are supposed to use newfs_apfs, in a command such as
newfs_apfs -v Macintosh disk1s2
which is given as an example to format “a new container and a volume named ‘Macintosh’ on the /dev/disk1s2 device”. In any case, converting an HFS+ volume to APFS should make all this unnecessary, and create a container and a volume containing the existing files on the HFS+ volume.

In my testing here, on 10.12.6, apfs_hfs_convert reports that it creates an APFS container and an APFS volume, but the latter does not get mounted. Running (sudo) newfs_apfs -i -v APFS1 disk4s3 as in the example returns no error, but no APFS containers or volumes are created either.

It had earlier been suggested that, in order to get these commands to work properly, the HFS+ volume has to be converted to core storage using a command of the form
diskutil cs convert /Volumes/HFS1
That currently seems to have no effect on any of the above, and in any case was not necessary in 10.12.4 or 10.12.5.

So as far as I can tell at present, Apple has rendered the APFS commands in 10.12.6 effectively unusable for the creation of APFS storage or its containers, and they are also not yet ready to convert HFS+ volumes to APFS. If you want to create APFS storage, you will need to go back to a Mac still running 10.12.5 in order to do so. There, you do not have to create the volumes too: a command in 10.12.6 like
newfs_apfs -i -v APFS3 -A disk5
will add a new case-insensitive volume named APFS3 to the APFS container at disk5.

Furthermore, to mount any APFS volumes, you will have to eject the whole disk and then remount it, e.g. by turning the external drive off and back on again. Sierra 10.12.6 seems unable to mount new APFS volumes when they are freshly created.

Normalisation

When you do manage to create and mount APFS volumes, they behave impeccably with respect to normalisation of Unicode characters, even if they were originally created using the tools in Sierra 10.12.5, and regardless of whether a given volume is case-sensitive, or case-insensitive. All attempts to create files whose name differed only in their normalisation were correctly recognised, handled, and the user informed of the problem accurately.

This was true even on this case-sensitive APFS volume.

At present, defaults on all the macOS command tools are for case-sensitive APFS; as the default in Sierra and High Sierra is the case-insensitive variant, Apple also needs to change all the command tools to use that same default.

macOS Sierra 10.12.6 appears to work well with both new normalising variants of APFS. However, it is currently badly let down by the tools to support APFS. Apple will need to release a further update to Sierra no later than the release of High Sierra to ensure that those deficiencies are addressed. That update should include all the command tools and Disk Utility.