On Mon, Jan 21, 2008 at 03:31:02PM -0500, Kevin Ballard wrote: >> No, it's still broken, because of the Unicode-is-not-static problem. >> What happens when you start adding more composable characters, which >> some future version of HFS+ will start breaking apart? > > If you need a static representation, you normalize to a specific form. And > in fact, adding new composable characters doesn't matter, since if they > didn't exist before, you couldn't have possibly used them. Sure you can. Suppose you unpack the same tar file or zip file that contains one of these new-fangled characters, one on a MacOS 10.5 system, and one on a MacOS 10.9 system. How HFS+ will corrupt that filename will differ depending which version of MacOS you are running. Hence, normalizing the filename when you store it is stupid and broken. MacOS and its applications and libraries want to do normalization in the privacy of its own address space, that's it's business. It can pursue any fetish it wants, among consenting adults. Safe, sane and consensual, and all that... well, consensual, anyway. I'm not sure about "safe" and "sane".... My arguement is basically is that there is absolutely no value in what HFS+ is doing, by corrupting filenames --- if you want to call it "normalizing" them, fine, but since Unicode is not static, so you can't even call it a "canonical" form. It's just some random corruption of what was passed in at open(2) time, that can and will change depending on what version of MacOS you are running. If you want to play the insane Unicode game of "equivalent" characters, you have to do it at comparison time, so there's no point trying to "normalize" them when you store them. It doesn't buy you anything, and it causes all sorts of pain. > Your entire argument is based on the assumption that HFS+ "corrupts" > filenames in order to allow dumb clients to do byte comparisons, and I > don't believe that to be the case. OK, what's your reason for why HFS+ corrupts filenames? What do you think is its excuse? What problem does it solve? If the answer is "no reason at all, but because it *can*", according to the Great God Unicode, then that's really not very impressive.... - Ted - 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
