I'm happy that the filesystem treats name as sequences of bytes. Normalization should happen at a higher level.
[deleted]
APFS is not safe to use with names which have Unicode normalisation issues
11–20 of 191 posts
Re: APFS is not safe to use with names which have Unicode normalisation issues
#12To be honest, I blame Unicode. Why allow different representations for the same character, and then provide a normalized form anyway, except it's not one normalized form but several? Sounds like job security to me.
Blame the encodings that came before it: Latin-1 and Windows-1252, and all the other ones. Hindsight is always 20/20, y'know.
Re: APFS is not safe to use with names which have Unicode normalisation issues
#13To be honest, I blame Unicode. Why allow different representations for the same character, and then provide a normalized form anyway, except it's not one normalized form but several? Sounds like job security to me.
More like a typical outcome of design-by-committee.
Re: APFS is not safe to use with names which have Unicode normalisation issues
#14The title is click-bait and over-dramatises the issue. The choice of APFS is that a filename is a sequence of bytes. Nothing more, nothing less (feel free to correct me if I'm wrong here). If you want to see the kind of issues that path normalisation brings, check out this: https://github.com/thibaudgg/rb-fsevent/blob/master/ext/fsev... I'd like to believe that most developer would prefer the current behaviour over t…
The problem seems to come from the high-level APIs doing normalization. So if you have two files in a directory, one normalized and one not-normalized and open the non-normalized file, the high-level API will then normalize that filename and you open the wrong file. I've always disliked the practice of messing around with file paths (storing them, concatenating them, etc). I preferred the way that the Classic MacOS t…
I understand that the bookmark feature of NSURL is (more or less, but most more) the same. cit: "Whereas path- and file reference URLs are potentially fragile between launches of your app, a bookmark can usually be used to re-create a URL to a file even in cases where the file was moved or renamed."
Re: APFS is not safe to use with names which have Unicode normalisation issues
#15i guess we'll see a new option on the finder "show non-normalized files" next to "show hidden files" pretty soon.
i don't see how they could automatically solve all the potential mismatch issues otherwise.
Re: APFS is not safe to use with names which have Unicode normalisation issues
#16The real problem isn't whether filename normalization is a good/bad thing, the problem is Apple used to do it one way and is now switching without warning to doing it the other way . It's the logical end product of the odyssey from Apple's original philosophy of a resource and data fork model for files to the UNIX stream-of-bytes model for files. The UNIX model traditionally kept metadata about files separate (anyone…
Technically, .DS_Store is just Finder data - where is the windows displaying the directory, it's dimensions, listing mode, etc.
The former resource fork is in ._$filename. You won't see it, unless you copy the file to smb share or zip it.
Re: APFS is not safe to use with names which have Unicode normalisation issues
#17Apparently on iOS 11, even the case-sensitive variant of APFS will be normalization-insensitive. Previously it looked like this would only be the case on macOS's case-insensitive APFS variant.
Anyway, it looks like the issues raised in this (April) blog post will not actually apply to iOS 11 or macOS High Sierra.
Re: APFS is not safe to use with names which have Unicode normalisation issues
#18To be honest, I blame Unicode. Why allow different representations for the same character, and then provide a normalized form anyway, except it's not one normalized form but several? Sounds like job security to me.
Blame the encodings that came before it: Latin-1 and Windows-1252, and all the other ones. Hindsight is always 20/20, y'know.
I'm just being sarcastic: should we also blame the computers of old for not being able to handle more than 255 characters ?
Re: APFS is not safe to use with names which have Unicode normalisation issues
#19The actual problem is not APFS but Apple's programs doing (and their advice to developers to do) normalization. It wouldn't be a problem if programs just used the file names given to them.
In fact, I think the normalization HFS+ does is more problematic. For example, fish shell can't complete file names when you use un-normalized characters in the input. [0][1]
Edit:
0: "Unicode normalization issues with HFS+" https://github.com/fish-shell/fish-shell/issues/474
1: "Completion does not work for special characters" https://github.com/fish-shell/fish-shell/issues/1794
Re: APFS is not safe to use with names which have Unicode normalisation issues
#20To be honest, I blame Unicode. Why allow different representations for the same character, and then provide a normalized form anyway, except it's not one normalized form but several? Sounds like job security to me.
Blame the encodings that came before it: Latin-1 and Windows-1252, and all the other ones. Hindsight is always 20/20, y'know.
I don't remember those having multiple representations for the same character in the same encoding or normal forms...