On Wed, 16 Jan 2008, Kevin Ballard wrote: > > It's not using different encodings, it's all Unicode. However, it accepts > different normalization variants of Unicode, since it can read them all and it > would be folly to require everybody to conform to its own special internal > variant. But it does have to normalize them, otherwise how would it detect the > same filename using different normalizations? That's a singularly *stupid* argument. Here, let me rephrase that same idiotic argument: "But it does have to uppercase them, otherwise how would it detect the same filename using different cases?" ..and if you don't see how that's *exactly* the same argument, you really are stupid. The fact is, normalization is wrong. It's wrong when you normalize upper/lower case (no, the word "Polish" is not the same as "polish"), and it's equally wrong when you normalize for "looks similar". > In other words, you're used to filenames as bytes, HFS+ treats filenames > as strings. No. HFS+ treats users as idiots and thinks that it should "fix" the filename for them. And it causes problems. It causes problems for exactly the same reasons case-independence causes problems, because it's EXACTLY THE SAME ISSUE. People may think that "but they are the same", but they aren't. Case matters. And so does "single character" vs "two character overlay". Does it always matter? Hell no. But the problem with a filesystem that thinks it knows better is that when it *sometimes* matters, the filesystem simply DOES THE WRONG THING. Can't you understand that? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html