5 ms·

I can't imagine why anyone would want a case insensitive file system, the logic makes sense from some abstract humanitarian viewpoint, but it makes no sense wha

by dusted 6y ago

I can't imagine why anyone would want a case insensitive file system, the logic makes sense from some abstract humanitarian viewpoint, but it makes no sense whatsoever that different identities should be mapped/translated to mean the same.. a.txt != A.txt != a.TXT and so on. They're different names of different files. Next generation *insensitive behavior should then be that cat.txt and neko.txt are the same (therefore only one of them allowed).

postalrat 6y ago
Filenames only exist for humans. I'm sure the machine would be plenty happy with just a number to identify each file. So if people prefer case insensitive names they should get them.
- ses1984 6y ago
  So then have another layer that shows insensitive things that point to files on the file system but leave the actual file system to simply map each unique identifier to a file.
  - pwinnski 6y ago
    That's what we have: inodes are unique identifiers, and names are for humans.
    - zajio1am 6y ago
      Well, that is not true. POSIX API is fundamentally filename (and filehandle) based, access rights are path (and therefore filename) based, while inodes have flat (per filesystem) namespace. Inodes are mostly internal implementation detail that unfortunately leaked into some abstractions.
      - pwinnski 6y ago
        As a matter of API, yes. Conceptually, though, inodes are unique per filesystem, and names are not. Given symbolic links, even assumptions about path+filename are not always correct.
- sumtechguy 6y ago
  NTFS is case sensitive. The default is to turn it off. That is a historical accident from its DOS roots. It works decently until you somehow manage to get two files with different cases in there. Had to chase that a few times 'what do you mean Abc.txt has not been edited there I clearly see a abc.txt' Then findout you are editing one and looking at the other. So case insensitive makes natural sense for my brain. But it can be infuriating if the system has edge cases where it will do both. Chased one a few months ago in an npm repo. The thing had 2 files. On the dev box works fine (windows). Off the build machine (linux) not so much. One happened to pick the right file the other did not.
- brmgb 6y ago
  Technically, POSIX machine already identifies each file using a serial number. This defines a specific inode. File names are stored into directory entries which are just specific files mapping names to inodes. Multiple names can already point to the same inode. So everything is determined by how you interpret directory entries.
sfvisser 6y ago
And I can’t imagine why you want to be able to identify multiple different files by similar names where only casing differs. This is a completely arbitrary opinion and nothing fundamental. > a.txt != A.txt != a.TXT and so on. They're different names of different files. Only if you define your != operator that way. It’s completely reasonable to have equality under some normalization.
DoofusOfDeath 6y ago
> but it makes no sense whatsoever that different identities should be mapped/translated to mean the same.. Doesn't Linux/Unix already have such ambiguity? E.g., multiple hard links to the same file; symbolic links; etc.?
- bartvanH 6y ago
  Yes, but then they have been made explicitly and they show up in a directory listing. If you would make the filesystem case insensitive ls would only show a.txt, but suddenly a "virtual" A.txt a.Txt etc would also exist. Now there are some folders on my machine that i would like to be case insensitive like ~/Downloads, never having to check if i downloaded distro.iso or Distro.iso would be nice. But i can see so many more problems with files i did not expect to exist and not showing up in my directory listing suddenly being there when i open something "else".
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.
trasz 6y ago
Allowing multiple files with the same file name - differing just by case - is rather silly from a human point of view. There are bigger problems, though - currently Linux allows having multiple files with the exact same file name, differing only by UTF-8 normalisation.
- Flimm 6y ago
  Yes, I would quite like to see Linux filesystems require that file names be in valid UTF-8, with no new lines, at the very least. Normalisation would be a bonus but I'd want to do it a way that is helpful for compatibility with macOS and Windows.
  - IshKebab 6y ago
    That would definitely be a breaking change. I had some Python code that broke when running over the Boost source code because they include a test file in there that isn't valid UTF-8, so the files definitely exist. Admittedly that's a fairly contrived example (i.e. the deliberately didn't use UTF-8). Maybe it wouldn't be so bad in practice.
  - trasz 6y ago
    There are two ZFS options, “normalization” and “utf8only”, which are documented to do precisely this (https://www.freebsd.org/cgi/man.cgi?zfs https://www.freebsd.org/cgi/man.cgi?zfs). Never used it myself, though.
- silvestrov 6y ago
  Why? We are used to that a lot of stuff can have the same name. Many humans have the same name. Having a unique name is uncommon.
- Firadeoclus 6y ago
  > Allowing multiple files with the same file name - differing just by case - is rather silly from a human point of view. In the current paradigm where files are predominantly accessed by a path and filename, yes. But that need not be the only nor the best way of referring to persistently stored data.
vii 6y ago
It's definitely true that case-folding is generalisable to more generous equivalence notions - for example, more or less whitespace isn't a noticeable difference that people typically want two files for. People casually using their phones want to treat the filesystem as a search tool where fuzzy matches (across different directories and names) are reasonable responses to file system queries. There have been many attempts at it like WinFS, but that's a significant increase in scope from case-folding. One incontrovertible justification for case-folding is to support Samba shares efficiently. Samba has to implement case-folding to clients and if it is not done in the filesystem datastructures you have to read in many directory entries to figure out if one would match with case-folding. There is plenty of MS Windows and MacOS software that just expects case-folding from the operating system. The article is old and this was released in 5.2. It can be turned on per (empty) directory with chattr https://kernelnewbies.org/Linux_5.2#Optional_support_for_case-insensitive_names_in_ext4 https://kernelnewbies.org/Linux_5.2#Optional_support_for_cas...
captainmuon 6y ago
I'm not even sure case insensitivity would be the naive human thing to expect. When I first made contact with computers (and typewriters!) in elementary school around 1990, whenever I pushed space while holding shift I got worried that I created an "uppercase space" and quickly deleted it with backspace. I kept that habbit for quite a long time.
michal_f 6y ago
Having many files with same name, differing in case only (a cultural 'thing') is just a mess - there's no extra value here. Do you use case in spoken word ? Arguments of performance or ease of implementation are technical details nobody cares (except devs of course :) ) We just end up living with this decission and there's no easy way out.
- michaelmrose 6y ago
  Can't you trivially solve this without addressing any of the 17 problems with case insensitivity by just not creating afile.txt and aFile.txt. In TB of data including files from the last 17 years I don't think I have any folders like that.
NelsonMinar 6y ago
Ask Apple. It's one of the most persistent annoyances of MacOS as a Unix.

by dusted 6y ago

postalrat 6y ago

Filenames only exist for humans. I'm sure the machine would be plenty happy with just a number to identify each file. So if people prefer case insensitive names they should get them.

ses1984 6y ago
So then have another layer that shows insensitive things that point to files on the file system but leave the actual file system to simply map each unique identifier to a file.
- pwinnski 6y ago
  That's what we have: inodes are unique identifiers, and names are for humans.
  - zajio1am 6y ago
    Well, that is not true. POSIX API is fundamentally filename (and filehandle) based, access rights are path (and therefore filename) based, while inodes have flat (per filesystem) namespace. Inodes are mostly internal implementation detail that unfortunately leaked into some abstractions.
    - pwinnski 6y ago
      As a matter of API, yes. Conceptually, though, inodes are unique per filesystem, and names are not. Given symbolic links, even assumptions about path+filename are not always correct.
sumtechguy 6y ago
NTFS is case sensitive. The default is to turn it off. That is a historical accident from its DOS roots. It works decently until you somehow manage to get two files with different cases in there. Had to chase that a few times 'what do you mean Abc.txt has not been edited there I clearly see a abc.txt' Then findout you are editing one and looking at the other. So case insensitive makes natural sense for my brain. But it can be infuriating if the system has edge cases where it will do both. Chased one a few months ago in an npm repo. The thing had 2 files. On the dev box works fine (windows). Off the build machine (linux) not so much. One happened to pick the right file the other did not.
brmgb 6y ago
Technically, POSIX machine already identifies each file using a serial number. This defines a specific inode. File names are stored into directory entries which are just specific files mapping names to inodes. Multiple names can already point to the same inode. So everything is determined by how you interpret directory entries.

sfvisser 6y ago

And I can’t imagine why you want to be able to identify multiple different files by similar names where only casing differs. This is a completely arbitrary opinion and nothing fundamental. > a.txt != A.txt != a.TXT and so on. They're different names of different files. Only if you define your != operator that way. It’s completely reasonable to have equality under some normalization.

DoofusOfDeath 6y ago

> but it makes no sense whatsoever that different identities should be mapped/translated to mean the same.. Doesn't Linux/Unix already have such ambiguity? E.g., multiple hard links to the same file; symbolic links; etc.?

bartvanH 6y ago
Yes, but then they have been made explicitly and they show up in a directory listing. If you would make the filesystem case insensitive ls would only show a.txt, but suddenly a "virtual" A.txt a.Txt etc would also exist. Now there are some folders on my machine that i would like to be case insensitive like ~/Downloads, never having to check if i downloaded distro.iso or Distro.iso would be nice. But i can see so many more problems with files i did not expect to exist and not showing up in my directory listing suddenly being there when i open something "else".

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.

trasz 6y ago

Allowing multiple files with the same file name - differing just by case - is rather silly from a human point of view. There are bigger problems, though - currently Linux allows having multiple files with the exact same file name, differing only by UTF-8 normalisation.

Flimm 6y ago
Yes, I would quite like to see Linux filesystems require that file names be in valid UTF-8, with no new lines, at the very least. Normalisation would be a bonus but I'd want to do it a way that is helpful for compatibility with macOS and Windows.
- IshKebab 6y ago
  That would definitely be a breaking change. I had some Python code that broke when running over the Boost source code because they include a test file in there that isn't valid UTF-8, so the files definitely exist. Admittedly that's a fairly contrived example (i.e. the deliberately didn't use UTF-8). Maybe it wouldn't be so bad in practice.
- trasz 6y ago
  There are two ZFS options, “normalization” and “utf8only”, which are documented to do precisely this (https://www.freebsd.org/cgi/man.cgi?zfs https://www.freebsd.org/cgi/man.cgi?zfs). Never used it myself, though.
silvestrov 6y ago
Why? We are used to that a lot of stuff can have the same name. Many humans have the same name. Having a unique name is uncommon.
Firadeoclus 6y ago
> Allowing multiple files with the same file name - differing just by case - is rather silly from a human point of view. In the current paradigm where files are predominantly accessed by a path and filename, yes. But that need not be the only nor the best way of referring to persistently stored data.

vii 6y ago

It's definitely true that case-folding is generalisable to more generous equivalence notions - for example, more or less whitespace isn't a noticeable difference that people typically want two files for. People casually using their phones want to treat the filesystem as a search tool where fuzzy matches (across different directories and names) are reasonable responses to file system queries. There have been many attempts at it like WinFS, but that's a significant increase in scope from case-folding. One incontrovertible justification for case-folding is to support Samba shares efficiently. Samba has to implement case-folding to clients and if it is not done in the filesystem datastructures you have to read in many directory entries to figure out if one would match with case-folding. There is plenty of MS Windows and MacOS software that just expects case-folding from the operating system. The article is old and this was released in 5.2. It can be turned on per (empty) directory with chattr https://kernelnewbies.org/Linux_5.2#Optional_support_for_case-insensitive_names_in_ext4 https://kernelnewbies.org/Linux_5.2#Optional_support_for_cas...

captainmuon 6y ago

I'm not even sure case insensitivity would be the naive human thing to expect. When I first made contact with computers (and typewriters!) in elementary school around 1990, whenever I pushed space while holding shift I got worried that I created an "uppercase space" and quickly deleted it with backspace. I kept that habbit for quite a long time.

michal_f 6y ago

Having many files with same name, differing in case only (a cultural 'thing') is just a mess - there's no extra value here. Do you use case in spoken word ? Arguments of performance or ease of implementation are technical details nobody cares (except devs of course :) ) We just end up living with this decission and there's no easy way out.

michaelmrose 6y ago
Can't you trivially solve this without addressing any of the 17 problems with case insensitivity by just not creating afile.txt and aFile.txt. In TB of data including files from the last 17 years I don't think I have any folders like that.

NelsonMinar 6y ago

Ask Apple. It's one of the most persistent annoyances of MacOS as a Unix.