A Rose by Any Other Name...

Started by
16 comments, last by Ectara 9 years, 11 months ago


I think that's a different issue - isn't that just a matter of the filesystem not actually enforcing full case-insensitivity? I would expect a case-insensitive file system to be able to deterministically pick one or the other, ie. reject naming a file "File.txt" if there already existed a file "file.txt" in that directory while still preserving the casing of whatever filename I originally gave it.

It's not really about issues within your own case-insensitive file system. It's more about the inevitable issues that arise if you physically plug in, or mount over the network, a drive with different case-sensitivity rules.

Even on windows, you can obtain a variety of 3rd-party drivers for natively case-sensitive file systems (ext3, HFS+, and so on). These drivers have to perform some truly ghastly file name transforms to ensure that case-insensitive windows APIs don't screw up the contents of the disk.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement


How about on case-sensitivity?

...That doesn't quite answer the question. As outlined, there are other languages (disregarding accents) that have different character sets that can be substituted for each other (barring grammatical convention). When we think "case-insensitive", we tend to think of common Germanic, Romance, Indo-European, etc. languages only. There's a potential for this behavior in other languages that we intentionally ignore. It seems rather strange to have this core kernel feature that is only effective for a portion of the languages spoken by the user base, and thus, I don't feel that it belongs in the kernel. It seems like an esoteric part of the time period where a subset of the English alphabet was all we cared about, with everyone else as an after-thought.


I think that's a different issue - isn't that just a matter of the filesystem not actually enforcing full case-insensitivity?

swiftcoder nailed this one precisely - I frequently dual-boot between Windows and Linux. I could mount my NTFS partition right now and create two files that differ in name only by case. It doesn't seem wise to pretend that this can't happen (though, I know it will forever stick around due to the compatibility issues of ever changing it).


My stance is that case-insensitive filesystems (for those language for which case is actually a relevant concept) are more convenient to the user than case-sensitive filesystems.

Though I'm a developer, I'm also a user: I find it a big pain. Nothing like trying to find something you've referred to, only to have trouble finding it because it wasn't named with the case that you've always that it had. I find case-sensitivity to be very brittle; any break in the case-sensitive seal, and all hell breaks loose. Often, as a user, I find that software doesn't do case insensitivity properly.

This reminds me of a bug in the product inventory software I had written at work. To make life easier on the people entering the data for product listings, you could enter a partial name, and it would show a drop-down list of possible matches based on a case-insensitive search. Well, it would search case-insensitively, and it would find it for display, but if you didn't click on it and have it fill out the correct name for you, and you didn't type in the correct case, it would pass the check to see if it is in the database (case-insensitively) after submitting, but it would choke when it accidentally looked up the ID of the product in a case-sensitive manner, resulting in several listing records having null product IDs, failing after the input was already validated.

My point to the story is that if you ever decide to uphold case-sensitivity, your workload is now doubled: if you slip up even once and do something in a case-sensitive manner, it may produce serious bugs that defy expectations, especially if it fails on the backend, after the input's already declared valid.

This is why I feel that case-insensitivity should be in the top-most layer, facing the user, and out of the core:

  1. It is only useful for part of the user base.
  2. Not all users enjoy the feature; many hate it, especially those that spend more time in other operating systems.
  3. It is very brittle.

This topic is closed to new replies.

Advertisement