What?

Great Ghoulessarian. Please, please, please tell me you’re kidding.

That’s one of the craziest things I’ve ever heard. Wow.

To be honest, I hadn’t even considered the second point, even though I had puzzled over the problem Mac OS X has, where it shows certain user folders in the Finder according to the user’s locale. So, ~/Music will be translated into the user’s language, even though it is still ~/Music at the filesystem level. This feature can cause much confusion.

This leads me to think that we really need both a posix style filesystem, with very simple rules, and there’s probably a very good case (excuse pun) for a higher level of filesystem that supports locale dependant features – a filesystem designed for actual people, implemented on top of a posix filesystem, but well documented so there is not confusion about what a file’s name actually is (and of course then the name would be free of having to store other meta data for the file, the name would simply be a name).

You’re mistaken. If you read the comments, you’d see that we hashed this out quite a bit.

Case-insensitive/case-preserving is not stupid as a desired behavior for end users. You’re right about that.

It is, however, stupid as a ‘feature’ to be built into the filesystem. The presentation layer should be enforcing this behavior, not the filesystem.

I said it before, and I’ll say it again: not all “users” are people. Some users are machines. Some machines have to serve other machines that may have different filesystem semantics. By building case-insensitivity in to your filesystem you are hanging a big sign on it that says “I am not serious about competing in the enterprise” (and yes, Faisal, I disagree with your belief that because a few banks have installed NTFS that that belies my statement: NTFS supports case-sensitive filenames.)

The fact that Apple rolled out a case-sensitive option after they introduced the Xserve and nobody bought it is evidence of this.

Witness how LWP::Perl’s /usr/bin/HEAD collides with /usr/bin/head. That could’ve been avoided if the LWP::Perl developers had had the actual sense to THINK OF ANOTHER USEFUL NAME rather than going “oh well, we’ll just uppercase it”. F-ing ridiculous and it’s that standard braindead carry-over from UNIX filesystems and academia that is ruining it.

Wonder why Windows and Mac use case-insensitivity? Because it makes sense to the non-nerds.

I agree that having the case-sensitive option is a good thing, largely for compatibility reasons, but it’s the wrong default choice for a consumer OS. I also don’t buy that case sensitivity is an issue for the enterprise market, or Windows would be nowhere.

Of course, this is a major reason that MacOS never penetrated into the enterprise market. It’s also a major reason Apple implicitly admitted their mistake and offered case-sensitive HFS+.

Again, it’s clear that “make things seem case-insensitive” is a useful and valuable behavior for users, but what’s brain-damaged is implementing that restriction at the filesystem layer rather than at the user interface layer.

Another way to phrase this is: “Don’t tell Oracle how to name their files, stupid.”

(Actually, IIRC, the real issue was that making HFS+ case-sensitive at the start would instantly break lots of Mac apps which assumed the same sorts of file system semantics as OS9 had. It would also likely cause all sorts of trouble for average users who don’t give a care for UNIX.)

I have a conceptual issue with any possible file naming conflicts at the file system level. If it is the same name in any language or any case, abstract it and maintain a reference elsewhere.

Look at the havoc it can cause with webservices or when going from EBCDIC to ASCII.

JMTCW