SpaceCadet

You're probably joking, but in case you don't know: LPT stands for Line Printer Terminal, and LPT1, LPT2, LPT3... referred to parallel ports which were typically (though not exclusively) used to connect a printer.

The thing is, a lot of the legacy backwards compatible stuff that's in Linux is because a lot of things in Unix were actually pretty well thought out from the get go, unlike many of the ugly hacks that went into MSDOS and later Windows and overstayed their welcome.

Things like: long case sensitive file names from the beginning instead of forced uppercase 8.3 , a hierarchical filesystem instead of drive letters, "everything is a file" concept, a notion of multiple users and permissions, pre-emptive multitasking, proper virtual memory management instead of a "640k is enough" + XMS + EMS, and so on.

Or just name the file con. Windows 95 even used to bluescreen if you tried to refer to con\con.

To screw with Windows users, you should sometimes put a README.md as well as a README.MD in your git repos. It leads to interesting results.

If you rename a file only changing the casing it doesn’t update properly, you need to rename it to something else and back. This is so userfriendly I have been stumped by it multiple times.

To my great surprise, this has been fixed. I don't know when, but I tried it on my Windows 10 VM and it just worked. Only took them 20 years or so :)

I would argue that elegance and being easy to program are virtues by themselves, because it makes code easy to understand and easy to maintain.

A one-to-one string to filename mapping is straightforward and elegant. It's easy to understand ("a filename is a unique string of characters"), it makes file name comparisons easy (a bit level compare suffices) and as long as you consistently use the case that you intend, it doesn't behave unexpectedly. It really is the way of the least surprise.

After all, case often does have meaning, so why shouldn't it be treated as a meaningful part of a filename? For example: "French fries.jpg" could contain a picture of fries specifically made in France, whereas "french fries.jpg" could contain a picture of fries made anywhere. Or "November rain.mp3" could be the sound of rain falling in the month of November, whereas "November Rain.mp3" is a Guns N' Roses song. All silly examples of course, but they're merely to demonstrate that capitalization does have meaning, and so we should be able to express that canonically in filenames as well.

It actually seems like it even works in explorer nowadays. I'll be damned, they fixed something...

The point is you have to take this into account, so the decision to go with a case insensitive file system has ripple effects much further down your system. You have to design around it at every step in code where a string variable results in a file being written to or read from.

It's much more elegant if you can simply assume that a particular string will 1-on-1 match with a unique filename.

Even Microsoft understands this btw, their Azure Blob Storage system is case sensitive. The only reason NTFS isn't (by default) is because of legacy. It had to be compatible with all uppercase 8.3 filenames from DOS/FAT16.

give me one use case where it makes sense having several files with the same name but different cases in the same directory

Imagine a table in a database where the primary key is a case sensitive character field, because you know varchars, just like C char types and string types in other languages are case sensitive.

Imagine a database administrator does the following:

• Export all data with primary key = 'Abcde' to 'Abcde.csv'

Imagine a second database adminstrator around the same time does the following:

• Export all data with primary key = 'abcde' to 'abcde.csv'

Now imagine this is the GDPR data of two different users.

If you have a case insensitive file system, you've just overwritten something you shouldn't have and possibly even leaked confidential data.

If you have a case sensitive file system you don't have to account for this scenario. If the PK is unique, the filename will be unique, end of story.

Because it’s designed for average people

It is not. It is designed for all purposes, automated processes and people alike. A filesystem is not just for grandma's Word documents.

And even people's names are case sensitive. My name has the format Aaa Bbb ccc Ddd. It is not the same as the person with the name Aaa Bbb Ccc Ddd, who also exists. So why shouldn't file names be?

I don’t think there’s a need for File.txt and fILE.txt

It's not so much about that need. It's about it being programmatically correct. f and F are not the same ASCII or UTF-8 character, so why would a file system treat them the same?

Having a direct char type to filename mapping, without unnecessary hocus pocus in between, is the simple and elegant solution.

Even more annoying is that it's very cumbersome to change the case of a file once you've created it.

If you accidentally create fIle.txt when you meant File.txt, the rename function does nothing ... and it will keep displaying as fIle.txt. You have to rename it to something else entirely, then rename it back to the original name with the intended case.