On Mon, Jan 21, 2008 at 03:01:43PM -0500, Kevin Ballard wrote:
Well, why are you arguing on the git list about precisely that (when
you reponsed to Linus), then?
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?
Presumably the whole *reason* why HFS+ was corrupting strings was so
that "stupid applications" that only did byte comparisons would work
correctly. But when you upgrade from Mac OS 10.5 to 10.6, and it adds
support for new composable characters, and you now take a USB hard
drive that was hooked up to a MacBook Air, running one version of
MacOS, and hook it up to another Macintosh, running another version of
MacOS, the normalization algorithm will be different, so the byte
comparisons won't work.
So all of this extra work which MacOS put in to corrupt filenames
behind our back doesn't actually do any good; applications still need
to be smart, or there will be rare, hard to reproduce bugs
nevertheless. So if MacOS wants to supply Unicode libraries that
compare strings keeping in mind Unicode "equivalences" it can be our
guest (although how they deal with different versions of Unicode with
different equivalence classes will be their cross to bear). BUT MacOS
X SHOULD NOT BE CORRUPTING FILENAMES. TO DO SO IS BROKEN.
Even Microsoft got this right; its filesystem is case-preserving, but
it has case-insensitive lookups. Hence, it is not corrupting
filenames behind the application's back, unlike MacOS.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html