To clarify: the thing I want to point out that the decision to *hash* the
filenames in a case-insensitive hash, is very different from the decision
to then *compare* the filenames when traversing the hash with a
case-insensitive compare.
And this difference is actually very important. Hashing things together
that are "equivalent" according to any random rule is what makes it
possible to then *check* for equivalence cheaply (because you only need to
make the potentially expensive check with the subset of cases where it
might trigger), but it in no way forces you to actually recode or mangle
or compare things equivalently.
In fact, I'd argue that this is what HFS+ did wrong in the first place:
they had stupid/incompetent people who didn't understand about this, so
they normalized the string *before* the hashing rather than as part of the
hash itself, and thus actually corrupt the string itself.
So what you can do (and I'd argue that we do) is to have a hash that can
handle almost arbitrary input, but then never corrupt the filename, and
always compare exactly by default.
Then, depending on a config option, we can decide to change the compare so
that equivalent (according to whatever rule) filenames either cause a
warning (people on sane filesystems, but working with people who aren't),
or are silently considered the same file (people on insane filesystems).
Linus
-
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
