On Wed, 23 Jan 2008, Linus Torvalds wrote: > > > But I really hope that you are not proposing to use the case-ignoring > > hash when we are _not_ on a case-challenged filesystem... > > I actually suspect that we could, and nobody will notice. The hash would > cause a few more collissions, but not so you'd know. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
