Perils of Case-insensitivity in OS X

[ewmayer]

http://itre.cis.upenn.edu/~myl/langu...es/003222.html

[Greenbank]

Sorry, but the fact that OS X is, by default, case-insensitive does not warrant that much text. As the page says, DOS is the same.

The fact that other operating systems are case sensitive is interesting but not that useful.

Say I've got 3 msieve.log files from 3 different factorisations, do I really want to store them as:-

msieve.log
Msieve.log
MsIeVe.LoG

just because I can? Or do I give them more appropriate names?

I can put annoying ASCII control charecters in the filenames, but I don't because it's a stupid thing to do.

[alpertron]

Originally Posted by http://itre.cis.upenn.edu/~myl/languagelog/archives/003222.html

I would have expected Windows to faithfully replicate every feature of other operating systems that really sucks, and then add stupid features of its own, plus bugs. And apparently that's right.

This is just plain nonsense. In DOS all file names were stored in the disk with capital letters. In FAT32 it was added the possibility of having files with mixed case, but for compatibility with DOS, the file system must be case insensitive.

[ewmayer]

I think the main issue is that Apple is marketing OS X as a Unix-like OS with lots of nifty search-related and GUI features, i.e. as the best of both the Unix and windows worlds. However, the case-insensitivity (which the example given in the first post shows is weirdly implemented, i.e. filenames are displayed as though they were case-sensitive, but they're really not) of OS X means it is *not* POSIX-compliant. This is a potentially dangerous source of confusion, made worse by semantics about kernel-versus-filesystem - for example, about OS X, Answers.com says:

Mac OS X (Mac OS 10) The current operating system from Apple for the Macintosh ... The heart of OS X is the open source, POSIX-compliant Darwin kernel

Now any reasonable person would assume that if an OS *kernel* is POSIX compliant (i.e. case-sensitive), that would also extend to any filesystem used by said kernel.

And I can think of numerous examples where the lack of case-sensitivity could be a real hassle for someone migrating from unix/lkinux to OS X - for example, what if you had some application that used a bunch of special character-font files, say A.font, B.font, etc. The obvious naming choice there is to use the case of the file prefix to indicate whether the font file contains the font data for an uppercase or lowercase letter.

Another example: I wrote a simple little javascript-based chess GUI last Fall, which displays the current state of the board via a table, each of whose squares is displayed using a small .gif image file of a specific piece on the appropriate-colored background. For each standard-piece image, there is a corresponding image with a color-modified background that is used to highlight if the given piece is in check (if a king) or unguarded and capturable by an enemy piece (if non-king). The regular and check-highlighted file names differ by - you guessed it - letter case, e.g. a black queen on a white square is bqw.gif, whereas if the same queen is open to capture, the display grabs the image file bQw.gif . Sure, I could modify the scheme so a threatened piece is denoted some other way, say bqwx.gif, but that would require no small amount of recoding, and loses the advantages of all filenames having the same length (which makes it easy to toggle the case of the piece character as needed). Why should every person migrating from unix or linux to OS X have to deal with this, when one or two developers at Apple could have saved everyone the hassle by adding some explicit information about this (and perhaps a simple user toggle) to the OS configuration manager software? Don't tell me your OS is POSIX-compliant if it's not.

[Greenbank]

Originally Posted by ewmayer

And I can think of numerous examples where the lack of case-sensitivity could be a real hassle for someone migrating from unix/lkinux to OS X - for example, what if you had some application that used a bunch of special character-font files, say A.font, B.font, etc. The obvious naming choice there is to use the case of the file prefix to indicate whether the font file contains the font data for an uppercase or lowercase letter.

Sorry but that's just bad design. What if you wanted to port that code over to a case-insensitive OS such as OS X? Lots of work. By using a naming scheme such as A_lower.font (for lower case) and A_upper.font (for upper case) you avoid these problems.

Originally Posted by ewmayer

Another example: I wrote a simple little javascript-based chess GUI last Fall, which displays the current state of the board via a table, each of whose squares is displayed using a small .gif image file of a specific piece on the appropriate-colored background. For each standard-piece image, there is a corresponding image with a color-modified background that is used to highlight if the given piece is in check (if a king) or unguarded and capturable by an enemy piece (if non-king). The regular and check-highlighted file names differ by - you guessed it - letter case, e.g. a black queen on a white square is bqw.gif, whereas if the same queen is open to capture, the display grabs the image file bQw.gif . Sure, I could modify the scheme so a threatened piece is denoted some other way, say bqwx.gif, but that would require no small amount of recoding, and loses the advantages of all filenames having the same length (which makes it easy to toggle the case of the piece character as needed). Why should every person migrating from unix or linux to OS X have to deal with this, when one or two developers at Apple could have saved everyone the hassle by adding some explicit information about this (and perhaps a simple user toggle) to the OS configuration manager software? Don't tell me your OS is POSIX-compliant if it's not.

With all due respect, that's just bad design again. Your code would not work on the most common OS in existence today (Windows) let alone Mac OS X.

A better design exists that is just as easy to implement and works across multiple platforms.

If you say "I never needed it to run on Windows or Mac OS X" then you don't have a problem. If you do need to run it then your original program was not designed to handle this, ergo bad design.

Also, writing a wrapper function to translate the names is trivial:-

abc.gif -> efgh.gif

e -> a
f -> tolower(b)
g -> c
h -> n, or y if isupper(b)

i.e.

bqw.gif -> bqwn.gif
bQw.gif -> bqwy.gif

Filenames are all the same length and the easy toggling is now just changing a character from y to n.

You shouldn't even need this anyway, you should have abstracted the filename generation out to a separate function so that the main body of code would not require any modifications if the naming schemes of files changed. In other words, you should have a function that given the input parameters of square colour, piece type, piece colour and 'vulnerability' it would return the appropriate filename. Then you only have to make changes in one place.