{"id":31177,"date":"2020-12-31T16:57:25","date_gmt":"2020-12-31T21:57:25","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31177"},"modified":"2020-12-31T16:57:25","modified_gmt":"2020-12-31T21:57:25","slug":"nsurl-smb-precomposed-character-bug","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/12\/31\/nsurl-smb-precomposed-character-bug\/","title":{"rendered":"NSURL\/SMB Precomposed Character Bug"},"content":{"rendered":"

Thomas Tempelmann<\/a> (tweet<\/a>):<\/p>\n

So, if a user on a Linux system creates a folder that contains an Umlaut such as “ü”, it’ll end up precomposed on the (ext4) file system.<\/p>

Now, I can nicely access files in such a folder from macOS, as long as I only use POSIX functions (which includes the shells such as bash and zsh).<\/p>

However, when I use NSURL<\/code> operations, some work and others give me a -260 error. For instance, getting NSURLCanonicalPathKey<\/code> fails, even in macOS 11.1. Other higher-level functions fail as well, such as trying to open the item with [NSWorkspace openURLs:…]<\/code>. The NSURL<\/code>’s path property does still hold the original precomposed name, and if I get the path and pass it to a POSIX function, it works. And some of the more basic getResource<\/code> accessors work as well. Just not the more complex ones.<\/p><\/blockquote>\n\n

This is not a surprise because, before relenting and adding Unicode normalization support to APFS, Apple tried to solve the problem in the Cocoa layer. But that only ended up being a partial solution, the result being that some APIs never worked properly until file system support was added. Now it seems that same code is doing unwanted conversions before the paths make it down to the lower level APIs.<\/p>\n\n

Previously:<\/p>\n