APFS Volume Names Are Still a Unicode Mess
This article stems from Thomas Tempelmann’s (@tempelorg) observation on Twitter that, if you name a volume in Disk Utility, it can remain in Unicode normalized Form C, which isn’t compatible with the rest of macOS, which expects Form D to be used.
[…]
If you do use Disk Utility to create two volumes with what appear to be identical names, but actually differ in their normalisation, then behaviours become stranger still.
[…]
The underlying problem seems to be a bug in Disk Utility, which fails to normalise volume names to Form D as the Finder does. But there’s also a bug in Spotlight indexing which results in volumes with Form C names not being indexed at all. APFS brought us many great things, but this initial design decision has only brought problems, complexity and bugs like these.
To all #Mac users who have accented chars (or umlauts) in their volume (disk) name: If #Spotlight doesn’t work for you, then try renaming your volume in Finder once to “abc”, then back to your preferred name. That might fix Spotlight.
Previously:
- NSURL/SMB Precomposed Character Bug
- APFS Native Normalization
- APFS to Add Case-Insensitive Variant for Mac
- APFS’s “Bag of Bytes” Filenames
2 Comments RSS · Twitter
This is a bad bug in Disk Utility, but it really is a design flaw in APFS. If an application written by Apple to manage disks can't get this right, there is no hope that getting the proper normalization can be left in the hands of application developers. Normalization should be solved once, at the lowest layers, so all applications can rely on this.
@Nick
I doubt it's an issue with APFS, because (a) it also happens with HFS+ volumes and (b) this is at the level of volume arbitration, _outside_ of the specific file system (such as APFS and HFS). APFS has unicode normalization pretty well under control by now, but handling volume names happens in different code, and that has not been adequately updated, it seems to me.
