Hacker News new | ask | show | jobs
by rickbad68 1639 days ago
A case sensitive filesystem doesn't require you to hit shift either if you just call the directory "programs". Also, there are many ways to save your pinky from moving the huge distance to the shift-key other than an arbitrary restriction on all file names in the file system..
1 comments

What are the advantages of using a case-sensitive file system? I cannot imagine a situation when you need to create two files that differ only in letter case. This also would make program that create such files not portable.
The primary advantage for me is simplicity. Case insensitive file systems are complicated when you start dealing with non-ASCII characters and different software implementing the case rules with subtle differences. With case sensitive file systems you know exactly what you get.
If you're going to move to non-ASCII characters, what about Unicode combining characters, do you have to care if your file named é is a single accented e or a pair of e-and-combining-accent before you can move it?

If you shouldn't have to care, if there should be a layer of Unicode normalization happening, why is that okay but case normalisation is not okay? If you do have to care, then you no longer "know exactly what you get".

> If you do have to care, then you no longer "know exactly what you get".

You do know you get exactly what you put in, whether that is é (U+00E9) or é (U+0065 U+0301). When you reference files created by yourself, this is not a problem as realistically speaking, your input method will only have a convenient way of forming one of these, and it will consistently generate the same one every time. When you reference files created by someone else, this may be a problem but no more than e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i): from the user's perspective, the problem is pretty much avoided by selecting the file using tab completion, TUIs, GUIs, whatever you use.

> e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i)...

Just want to remind a little but extremely important thing: There's absolutely no guarantees that upper("i") is I. There's at least one language breaks that convention, and you won't believe how a big headache is that.

Good point, Turkish uppercases i to İ. This adds complexity to the idea of case insensitive file systems even when only considering ASCII.
https://prnt.sc/257kxxa lowercase l and uppercase I are quite distinct. If you're going to select all your filenames with autocomplete, then why argue restrict me to case sensitive filenames?

Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.

For the record, this is how lowercase l and uppercase I show up here: https://prnt.sc/258zzy0
Well, it means you don't need to do things with Unicode casefolding tables in the middle of your not-eating-data fs code.