Hmmm. I doubt that, unless they were really bad programmers, downcasing (or upcasing) the file name in the file name accessors took much work, but I’ll grant it’s more than zero.
Wait… vfat supports Unicode? The filesystem that craps out if the file path length is longer than a couple hundred characters; that is an extension of a filesystem that couldn’t handle file names longer than 8.3 characters; that doesn’t have any concept of file permissions, much less ACLs; the one that partitioned filenames in 13 character hunks in directories to support filenames longer than 12 characters… that isn’t case sensitive, except in all the wrong ways - this filesystem can handle Unicode?
I greatly doubt that. FAT doesn’t even support 8-bit ASCII, does it? 7-bit only. Unless you mean FAT32, which can optionally have UTF-16 support enabled. And it’s far easier to manage case changes in UTF-16 than UTF-8, using case mapping as MS does. The API handles all of this for you; it keeps track of what the the user calls them, but uses it’s own internal name for the file. And na’er the two shall meet, lest there be trouble.
I do think it’s sloppy and lazy; it’s very easy to avoid doing actual work thinking about the problem and to bang out some hack solution. In the end, far more work is done, but for the wrong reasons.
I don’t know what Apple’s excuse is, except maybe DNA. Apple ][ were not only case insensitive, they didn’t even have lower case characters at all. There was only one case, and maybe those engineers brought that mind set forward with the Lisa, and then the Mac. How it got into Darwin… is Darwin really case insensitive? I’m pretty sure on the company line - at the filesystem level, it is.
Hmmm. I doubt that, unless they were really bad programmers, downcasing (or upcasing) the file name in the file name accessors took much work, but I’ll grant it’s more than zero.
I’ll retract the “lazy” comment.
That’s because you’re thinking in your tiny ASCII bubble. Switching case in Unicode is a hugely complex problem.
Wait… vfat supports Unicode? The filesystem that craps out if the file path length is longer than a couple hundred characters; that is an extension of a filesystem that couldn’t handle file names longer than 8.3 characters; that doesn’t have any concept of file permissions, much less ACLs; the one that partitioned filenames in 13 character hunks in directories to support filenames longer than 12 characters… that isn’t case sensitive, except in all the wrong ways - this filesystem can handle Unicode?
I greatly doubt that. FAT doesn’t even support 8-bit ASCII, does it? 7-bit only. Unless you mean FAT32, which can optionally have UTF-16 support enabled. And it’s far easier to manage case changes in UTF-16 than UTF-8, using case mapping as MS does. The API handles all of this for you; it keeps track of what the the user calls them, but uses it’s own internal name for the file. And na’er the two shall meet, lest there be trouble.
I do think it’s sloppy and lazy; it’s very easy to avoid doing actual work thinking about the problem and to bang out some hack solution. In the end, far more work is done, but for the wrong reasons.
I don’t know what Apple’s excuse is, except maybe DNA. Apple ][ were not only case insensitive, they didn’t even have lower case characters at all. There was only one case, and maybe those engineers brought that mind set forward with the Lisa, and then the Mac. How it got into Darwin… is Darwin really case insensitive? I’m pretty sure on the company line - at the filesystem level, it is.