3 ms·

For developers, sure, we know the difference. But it's very hard to explain to your mother that MyFile.docx is a different file to Myfile.docx. When I was in u

by llimos 6y ago

For developers, sure, we know the difference. But it's very hard to explain to your mother that MyFile.docx is a different file to Myfile.docx. When I was in university this was the argument given by the lecturer of the operating systems course in favour of CI, and I found it convincing. (FTR he is the author of 33 internet standards, and not a fan of Windows in most other ways.) Losing the ability to have two differently-cased filenames in the same directory doesn't seem like a great loss.

dusted 6y ago
It's rather intuitive that you can have multiple files. They're right there in your directory, and you see them: a.txt A.txt And you get that they're files.. It's just plain weird to do extra work to eliminate this freedom. I don't think anyone needs to explain it to anyone.. If you've already decided only to have files in one case, you'll never need to communicate this.. If you've decided to make use of both, you'll refer to them by their casing.. "mom, please open the myfile.txt, the one with an uppercase M", except, in writing, we don't even need to be so specific.. In my email to mom, I'll write "Please open MyFile.txt" and when mom sees theat there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant."
- Joker_vD 6y ago
  By that argument, you might as well have files with the same name, if you can "just see them". And let's not even start with non-English auditory where you have to render filenames as "С as a dollar, У, another С as a dollar, English T, E, M" (that's "system" btw).
  - toyg 6y ago
    I agree. I wish NATO alphabet could taught in schools and become the world standard for spelling the Latin alphabet; my quality of life improved significantly after I learnt it (by accident, on a job).
- toyg 6y ago
  > there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant. Your mom is pretty good at IT, clearly. In my experience, this sort of scenario with "normal users" will result in one of the following: - user opens both files and tries to figure out which one "looks better" for the task at hand. If questioned later, they will likely hide this fact to avoid having to admit their judgement was somehow involved. - user fires back an email saying "there are two files with that name !! Please do it for me, this is complicated !!11!" Case sensitivity looks like an advantage only to us nerds. There is a reason many systems go all-uppercase-all-the-time, even where they could easily use casing: it's a big source of confusion. Spoken language has no case, after all.
- Majromax 6y ago
  > In my email to mom, I'll write "Please open MyFile.txt" and when mom sees theat there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant." But if she (or any normal user) only sees 'myfile.txt' or "myFile.txt" or "Myfile.txt", she wouldn't respond with "that file doesn't exist." Instead, she'd be more likely to assume you made a mistake in your specification. Read through the comments on the LWN article: case insensitivity is a practical problem because user-space implementations (such as samba) must perform an O(N) check across all files in a directory before confirming that a file doesn't exist. At the same time, existing programs that assume case-insensitivity (coming from the Mac and Windows worlds, mostly) are often none too consistent about creating 'foo.txt' but opening it (potentially from another program) as 'FOO.TXT'.
zajio1am 6y ago
> But it's very hard to explain to your mother that MyFile.docx is a different file to Myfile.docx Why? Human languages are also case-sensitive (e.g. 'moon' and 'Moon' have different meanings). Nowadays, casual users rarely enter filenames by name, and for output, case-insensitive filesystems are still case-preserving (and users expect that). > Losing the ability to have two differently-cased filenames in the same directory doesn't seem like a great loss. It is not really about this ability, it is about plenty of direct implementation and usability issues that it causes, like: - it makes everything encoding-dependend (which complicates e.g. handling of mixed encoding filenames and filenames with invalid utf-8 sequences) - interoperability with case-sensitive systems (unpacking archive containing files differing in case) - backward compatibility (new unicode version adds new characters and their case mapping) Considering that case-sensitivity is not the only such issue (there is also different unicode normalizations and homographs) it seems to me that it make sense to have FS code and low-level utils encoding-independent (and therefore case-insensitive) and do case sensitivity (and perhaps. homograph handling) only in high level user code.
- IanCal 6y ago
  > Why? Human languages are also case-sensitive (e.g. 'moon' and 'Moon' have different meanings). You'd know I meant the same thing if I wrote "go to the moon" or "go to the Moon". If you wrote "Hi ian" and I replied "There's nobody here by that name, can't imagine who you might mean" you'd think I was being obtuse.
  - adeelk93 6y ago
    Humans by default make assumptions to error-correct. Computers don’t do that by default, but you could get bash (for example) to also make assumptions with a setting like: set completion-ignore-case On Personally, I’d prefer an obtuse computer over one that makes assumptions and is occasionally wrong.
    - IanCal 6y ago
      > Computers don’t do that by default Absolutely, but it's where I find people get tripped up who aren't as used to tech. The thing I have told the computer to do is technically wrong in a minor way but it's extremely obvious to anyone that looks at it what I want. There are multiple reasons why we usually want this to be the case (simpler to implement, cost of returning an error is low but the cost of automatically doing the wrong thing can be huge, etc). The rules aren't universal either. Some machines are fine with different casing, some aren't. Email addresses aren't case sensitive, typically, but my user name might be. Email addresses have to be exact, except with gmail where . isn't important, and anything after + is ignored. Google search from the omnibox will assume what it thinks you wanted to search for by default but urls entered in the same place are extremely picky.
freddie_mercury 6y ago
How about tonal marks (á, à, ạ, ã, ả) and "weird characters" (ơ,ư,â,ô) in languages like Vietnamese? Should the filesystem ignore those, too? After all, they are regularly left off in a lot of modern text based conversation. If I have "bài tập #14.pdf" and "bai tap #14.pdf" in the same directory, basically everyone is going to expect them to be the same thing, not different things. Trying to explain they are different because filesystem developers only understand English-centric conventions isn't exactly easy to explain either.

by llimos 6y ago

dusted 6y ago

It's rather intuitive that you can have multiple files. They're right there in your directory, and you see them: a.txt A.txt And you get that they're files.. It's just plain weird to do extra work to eliminate this freedom. I don't think anyone needs to explain it to anyone.. If you've already decided only to have files in one case, you'll never need to communicate this.. If you've decided to make use of both, you'll refer to them by their casing.. "mom, please open the myfile.txt, the one with an uppercase M", except, in writing, we don't even need to be so specific.. In my email to mom, I'll write "Please open MyFile.txt" and when mom sees theat there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant."

Joker_vD 6y ago
By that argument, you might as well have files with the same name, if you can "just see them". And let's not even start with non-English auditory where you have to render filenames as "С as a dollar, У, another С as a dollar, English T, E, M" (that's "system" btw).
- toyg 6y ago
  I agree. I wish NATO alphabet could taught in schools and become the world standard for spelling the Latin alphabet; my quality of life improved significantly after I learnt it (by accident, on a job).
toyg 6y ago
> there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant. Your mom is pretty good at IT, clearly. In my experience, this sort of scenario with "normal users" will result in one of the following: - user opens both files and tries to figure out which one "looks better" for the task at hand. If questioned later, they will likely hide this fact to avoid having to admit their judgement was somehow involved. - user fires back an email saying "there are two files with that name !! Please do it for me, this is complicated !!11!" Case sensitivity looks like an advantage only to us nerds. There is a reason many systems go all-uppercase-all-the-time, even where they could easily use casing: it's a big source of confusion. Spoken language has no case, after all.
Majromax 6y ago
> In my email to mom, I'll write "Please open MyFile.txt" and when mom sees theat there is a myFile.txt and MyFile.txt in the directory, she won't have trouble figuring out which one I meant." But if she (or any normal user) only sees 'myfile.txt' or "myFile.txt" or "Myfile.txt", she wouldn't respond with "that file doesn't exist." Instead, she'd be more likely to assume you made a mistake in your specification. Read through the comments on the LWN article: case insensitivity is a practical problem because user-space implementations (such as samba) must perform an O(N) check across all files in a directory before confirming that a file doesn't exist. At the same time, existing programs that assume case-insensitivity (coming from the Mac and Windows worlds, mostly) are often none too consistent about creating 'foo.txt' but opening it (potentially from another program) as 'FOO.TXT'.

zajio1am 6y ago

> But it's very hard to explain to your mother that MyFile.docx is a different file to Myfile.docx Why? Human languages are also case-sensitive (e.g. 'moon' and 'Moon' have different meanings). Nowadays, casual users rarely enter filenames by name, and for output, case-insensitive filesystems are still case-preserving (and users expect that). > Losing the ability to have two differently-cased filenames in the same directory doesn't seem like a great loss. It is not really about this ability, it is about plenty of direct implementation and usability issues that it causes, like: - it makes everything encoding-dependend (which complicates e.g. handling of mixed encoding filenames and filenames with invalid utf-8 sequences) - interoperability with case-sensitive systems (unpacking archive containing files differing in case) - backward compatibility (new unicode version adds new characters and their case mapping) Considering that case-sensitivity is not the only such issue (there is also different unicode normalizations and homographs) it seems to me that it make sense to have FS code and low-level utils encoding-independent (and therefore case-insensitive) and do case sensitivity (and perhaps. homograph handling) only in high level user code.

IanCal 6y ago
> Why? Human languages are also case-sensitive (e.g. 'moon' and 'Moon' have different meanings). You'd know I meant the same thing if I wrote "go to the moon" or "go to the Moon". If you wrote "Hi ian" and I replied "There's nobody here by that name, can't imagine who you might mean" you'd think I was being obtuse.
- adeelk93 6y ago
  Humans by default make assumptions to error-correct. Computers don’t do that by default, but you could get bash (for example) to also make assumptions with a setting like: set completion-ignore-case On Personally, I’d prefer an obtuse computer over one that makes assumptions and is occasionally wrong.
  - IanCal 6y ago
    > Computers don’t do that by default Absolutely, but it's where I find people get tripped up who aren't as used to tech. The thing I have told the computer to do is technically wrong in a minor way but it's extremely obvious to anyone that looks at it what I want. There are multiple reasons why we usually want this to be the case (simpler to implement, cost of returning an error is low but the cost of automatically doing the wrong thing can be huge, etc). The rules aren't universal either. Some machines are fine with different casing, some aren't. Email addresses aren't case sensitive, typically, but my user name might be. Email addresses have to be exact, except with gmail where . isn't important, and anything after + is ignored. Google search from the omnibox will assume what it thinks you wanted to search for by default but urls entered in the same place are extremely picky.

freddie_mercury 6y ago

How about tonal marks (á, à, ạ, ã, ả) and "weird characters" (ơ,ư,â,ô) in languages like Vietnamese? Should the filesystem ignore those, too? After all, they are regularly left off in a lot of modern text based conversation. If I have "bài tập #14.pdf" and "bai tap #14.pdf" in the same directory, basically everyone is going to expect them to be the same thing, not different things. Trying to explain they are different because filesystem developers only understand English-centric conventions isn't exactly easy to explain either.