7 ms·

I don't even understand why he doesn't like case insensitivity. I can't think of a reason to have two files with the same name that vary only in capitalisation.

by jiggy2011 12y ago

thirsteh 12y ago
I guess his complaint is that lower(str) == lower(ostr) is more code than str == ostr...? :)
- userbinator 12y ago
  A lot more code, if you count the fact that the definition of "case" varies between languages, some of which don't even have such a concept. Add to that Unicode's varying representations that are visually identical but different sequences of bytes, and you have one hell of morass to deal with.
  - thirsteh 12y ago
    But that's a pretty silly complaint if that's really his argument. Nobody except kernel devs cares if the kernel needs to do case folding when it's 98% a UX issue.
    - tankenmate 12y ago
      All users care once it, personally, impacts their performance and their security.
Afforess 12y ago
Case insensitivity only makes sense dealing with ASCII. Once you allow files and directory names with unicode characters, case insensitivity no longer makes any sense.
- duaneb 12y ago
  > Once you allow files and directory names with unicode characters, case insensitivity no longer makes any sense. I disagree. I don't think a program should make any assumptions about the filesystem namespace—it's up to the user how they want to configure it.
  - chousuke 12y ago
    I don't see your point. In every case where you depend on filenames to identify blobs of data, case-sensitivity (actually byte-sensitivity) is the only behaviour that a filesystem can reliably implement. Once you allow cases where two different byte sequences must be considered equal depending on configuration, your filesystem can no longer work reliably. Case sensitivity may bother users sometimes, but the filesystem is not the right place to solve that problem.
bunderbunder 12y ago
I think the main complaint would be that it means Linux users will create bugs and security holes if they aren't constantly keeping track of the fact that a huge chunk of the computing world doesn't follow the same convention. To me it smacks of a rather egregious failure to grasp Postel's law. And case-sensitivity is just bad UX for the 99% of computer users who aren't programmers or IT; perhaps it makes sense on Linux but Windows and OS X are dealing with a different audience and Linus's failure to give that fact some credit makes him come across as tone deaf.
psadauskas 12y ago
There was a pretty major security flaw in git (and probably numerous other tools) involving case-insensitive filesystems a month ago: https://github.com/blog/1938-vulnerability-announced-update-your-git-clients https://github.com/blog/1938-vulnerability-announced-update-... That's a pretty major downside, and I think the back story for his dislike of it.
rogerbinns 12y ago
Are these two names the same case insensitively? Pick and PICK. Hint: https://en.wikipedia.org/wiki/Dotted_and_dotless_I https://en.wikipedia.org/wiki/Dotted_and_dotless_I How about Straße, STRASSE and strasse? For an American audience, how about Résumé and RESUME and resume? How about Ⅸ and IX? Hint: https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat... The answer to all that is that it depends on the user and their locale settings. So to get this right you would have to pass the locale settings into system calls that go into the filesystem so it can do the right thing on every call. But then what happens if the locale later gets changed? Before some file names may be considered equivalent, but with the new one they are different and things break. Ok how about a system wide locale setting that can't be changed? Are you going to require a disk reformat each time a different user is on the system, or a multilingual user who travels? The right solution is exactly what Unix did in the first place. The filesystem stores names exactly as is without having to deal with locales. User space is then responsible for doing the right thing for a user. For example a word processor can treat Résumé and Resume as the same for Americans in file selection dialogs. User space already has to deal with all this, for example by sorting file names. Here is how hard that is http://www.unicode.org/reports/tr10/ http://www.unicode.org/reports/tr10/ and a simple example is if z comes before or after ö. Or when showing a list of Swedish names to a German user do you use Swedish or German sort order? A similar analogy is dealing with time. The best approach is to store the time as UTC in the filesystem and let user space show it in whatever way is relevant for the user. On the other hand if you store local time in the filesystem, you will end up in a world of hurt trying to work around that. (UTC to local time is a lossy conversion making local time back to UTC hard to work out.)
- archagon 12y ago
  But half the time, I'm having to deal with file access and creation in the terminal. That's as an important user experience to me (a power user) as anything in the GUI. Does Unix change the way the terminal handles files depending on the locale? My understanding is that it does not. (If it did, maybe that would be the best solution for everyone, but I imagine a lot of geeks would be up in arms about how the terminal experience is not consistent...)
Morgawr 12y ago
I always bring this up when people talk about case sensitive/insensitive. Traditionally, a machine only sees the difference in glyphs, not in letters. 'a' is a different glyph to 'A'. We are used to dealing with case sensitivity because that's the most common instance in the English language where we have collision in meaning but not in glyphs. Let's take other non-latin characters, like accented letters or cyrillic. Some of these alphabets have letters that act as 'a' but are not 'a'. Some of these alphabets have glyphs that look like 'a' but are not 'a'. All of these glyphs are encoded using different codes as seen by a machine. If you want to support 'a' == 'A', then I could argue that I would want you to support 'a' == 'A' == <letter in cyrillic that means 'a'>. It is a very slippery slope, in my opinion. Logically, I would rather have 'a' and 'A' separated to avoid ambiguity, but feel free to disagree.
dalke 12y ago
MacAdam.doc might be about the American physicist and color scientist David MacAdam. macadam.doc might be about a type of road construction.

I don't even understand why he doesn't like case insensitivity. I can't think of a reason to have two files with the same name that vary only in capitalisation.

thirsteh 12y ago

I guess his complaint is that lower(str) == lower(ostr) is more code than str == ostr...? :)

userbinator 12y ago
A lot more code, if you count the fact that the definition of "case" varies between languages, some of which don't even have such a concept. Add to that Unicode's varying representations that are visually identical but different sequences of bytes, and you have one hell of morass to deal with.
- thirsteh 12y ago
  But that's a pretty silly complaint if that's really his argument. Nobody except kernel devs cares if the kernel needs to do case folding when it's 98% a UX issue.
  - tankenmate 12y ago
    All users care once it, personally, impacts their performance and their security.

Afforess 12y ago

Case insensitivity only makes sense dealing with ASCII. Once you allow files and directory names with unicode characters, case insensitivity no longer makes any sense.

duaneb 12y ago
> Once you allow files and directory names with unicode characters, case insensitivity no longer makes any sense. I disagree. I don't think a program should make any assumptions about the filesystem namespace—it's up to the user how they want to configure it.
- chousuke 12y ago
  I don't see your point. In every case where you depend on filenames to identify blobs of data, case-sensitivity (actually byte-sensitivity) is the only behaviour that a filesystem can reliably implement. Once you allow cases where two different byte sequences must be considered equal depending on configuration, your filesystem can no longer work reliably. Case sensitivity may bother users sometimes, but the filesystem is not the right place to solve that problem.

bunderbunder 12y ago

I think the main complaint would be that it means Linux users will create bugs and security holes if they aren't constantly keeping track of the fact that a huge chunk of the computing world doesn't follow the same convention. To me it smacks of a rather egregious failure to grasp Postel's law. And case-sensitivity is just bad UX for the 99% of computer users who aren't programmers or IT; perhaps it makes sense on Linux but Windows and OS X are dealing with a different audience and Linus's failure to give that fact some credit makes him come across as tone deaf.

psadauskas 12y ago

There was a pretty major security flaw in git (and probably numerous other tools) involving case-insensitive filesystems a month ago: https://github.com/blog/1938-vulnerability-announced-update-your-git-clients https://github.com/blog/1938-vulnerability-announced-update-... That's a pretty major downside, and I think the back story for his dislike of it.

rogerbinns 12y ago

Are these two names the same case insensitively? Pick and PICK. Hint: https://en.wikipedia.org/wiki/Dotted_and_dotless_I https://en.wikipedia.org/wiki/Dotted_and_dotless_I How about Straße, STRASSE and strasse? For an American audience, how about Résumé and RESUME and resume? How about Ⅸ and IX? Hint: https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat... The answer to all that is that it depends on the user and their locale settings. So to get this right you would have to pass the locale settings into system calls that go into the filesystem so it can do the right thing on every call. But then what happens if the locale later gets changed? Before some file names may be considered equivalent, but with the new one they are different and things break. Ok how about a system wide locale setting that can't be changed? Are you going to require a disk reformat each time a different user is on the system, or a multilingual user who travels? The right solution is exactly what Unix did in the first place. The filesystem stores names exactly as is without having to deal with locales. User space is then responsible for doing the right thing for a user. For example a word processor can treat Résumé and Resume as the same for Americans in file selection dialogs. User space already has to deal with all this, for example by sorting file names. Here is how hard that is http://www.unicode.org/reports/tr10/ http://www.unicode.org/reports/tr10/ and a simple example is if z comes before or after ö. Or when showing a list of Swedish names to a German user do you use Swedish or German sort order? A similar analogy is dealing with time. The best approach is to store the time as UTC in the filesystem and let user space show it in whatever way is relevant for the user. On the other hand if you store local time in the filesystem, you will end up in a world of hurt trying to work around that. (UTC to local time is a lossy conversion making local time back to UTC hard to work out.)

archagon 12y ago
But half the time, I'm having to deal with file access and creation in the terminal. That's as an important user experience to me (a power user) as anything in the GUI. Does Unix change the way the terminal handles files depending on the locale? My understanding is that it does not. (If it did, maybe that would be the best solution for everyone, but I imagine a lot of geeks would be up in arms about how the terminal experience is not consistent...)

Morgawr 12y ago

I always bring this up when people talk about case sensitive/insensitive. Traditionally, a machine only sees the difference in glyphs, not in letters. 'a' is a different glyph to 'A'. We are used to dealing with case sensitivity because that's the most common instance in the English language where we have collision in meaning but not in glyphs. Let's take other non-latin characters, like accented letters or cyrillic. Some of these alphabets have letters that act as 'a' but are not 'a'. Some of these alphabets have glyphs that look like 'a' but are not 'a'. All of these glyphs are encoded using different codes as seen by a machine. If you want to support 'a' == 'A', then I could argue that I would want you to support 'a' == 'A' == <letter in cyrillic that means 'a'>. It is a very slippery slope, in my opinion. Logically, I would rather have 'a' and 'A' separated to avoid ambiguity, but feel free to disagree.

dalke 12y ago

MacAdam.doc might be about the American physicist and color scientist David MacAdam. macadam.doc might be about a type of road construction.