It actually seems like it even works in explorer nowadays. I'll be damned, they fixed something...
SpaceCadet
joined 2 years ago
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.
This isn't "Windows design"... this is just inherited stone age bullshit from the DOS days when the filesystem was FAT16 and all file names were uppercase 8.3.
NTFS is case sensitive in its underlying design, but was made case insensitive by default, yet case preserving, for reasons of backwards compatibility.
If Microsoft has to design something from scratch, without the need for backwards compatibility, they go for case sensitive themselves. For example: Azure Blob Storage has case sensitive file names.
Due to the energy crisis in Europe at the beginning of the Russian invasion of Ukraine, as a cost saving measure some cities here in Belgium decided to turn off the street lights at a certain time. I think they went dark at 23:00 or 22:00, so your Cinderella Lighting scenario.
I thought it felt quite peaceful to have some true darkness, and wouldn't mind it back, but at the same time if you had to walk outside at that time, it could feel a bit unsettling even if I live in a very safe neighborhood. I also found that there were some practical issues like, not being able to see obstacles or the state of the pavement, so you had to tread carefully. I'd definitely buy a decent flashlight if they implement that again.
Later, I suppose after complaints from citizens, they reverted to turning only every other streetlight off. I didn't like that at all, it was the worst of both worlds. There were still patches where you couldn't see properly, but none of the peaceful feeling of true darkness. Since a year or so it's back to all streetlights all night.
Language is simply the intrafrastructure by which we touch another’s mind across space and time
And grammar is the tool we use to structure our thoughts into intelligible phrases, so that our words convey the correct meaning to our audience. Sure everyone makes grammar mistakes occasionally, but if you respect your audience, you should at least attempt to use proper grammar and graciously accept it as a learning opportunity when a mistake is pointed out.
a bash script to reinstall f—ing everything again
Why would you ever want to do that?
First of all, almost any Arch update induced problem can be solved by downgrading the offending package to the previous version, which handily is available in /var/cache/pacman/pkg/. This is an essential Arch troubleshooting skill.
Even an unbootable system (which has only happened once in my 10 years of using Arch because I didn't read important news) can be fixed this way, because you can always boot from the installation usb stick and then use arch-chroot to access your installation and fix problems.
Secondly, if the problem was indeed caused by an Arch update, you will just reinstall the problem if you run a reinstall script.
I mean there's plenty of space for it between Iceland and Ireland, and it would close the GIUK gap...
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.