But why though? Do you really want a bunch of file.txt File.txt FILE.txt fIle.txt FiLe.txt FIle.txt flIe.txt… I once had a nasty bug the O in a file name was a 0 and I didn’t notice I can’t imagine the horrors this would cause.
Yeah I’ve definitely run into issues where case sensitivity causes problems. Especially in programs that are cross-functional between Windows and Linux. Like when I recently downloaded some bios files for a Playstation emulator and I spend time figuring out and troubleshooting why they weren’t working until it finally hit me the door McFly it’s cause the file name was in lowercase not uppercase. Than I cared to admit to figure out
Oooh, I’ve had that with some device. I think it was a camera or something like that. I’d forgotten about it. It took me ages to figure it out.
Thought experiment: Would you expect a programming language variable name to be case insensitive?
That is, if you set
foo = 1and thenprint FOO, what should happen? Most programming languages throw an error.Is this even comparable with filenames, which are, after all, basically variable names that hold large quantities of data?
If there is a difference, is it the fact it’s a file, or - for a mad idea - should files with only a few bytes of data retain case insensitivity? And if that idea is followed through, where’s the cutoff? 256 bytes? 7?
(Anyway, Windows filenames are case sensitive, in a sense. If you save “Letter to Grandma.txt” it will retain those two capital letters and all the lower case letters exactly as they are. It won’t suddenly change to “LETTER to Grandma.txt”, despite the fact that if you try to open a file by that name, you’ll get the same file.)
PowerShell variable names and function names are not case sensitive.
I understand the conventions of using capitalization of those names having specific meanings in regards to things like constants, but the overwhelming majority of us all use IDEs now with autocomplete.
Personally, I prefer to use prefixes anyway to denote that info. Works better with segmenting stuff for autocomplete, and has less overhead of deriving non-explicit meaning from stuff like formatting or capitalization choices.
On top of that, you really shouldn’t be using variables with the same name but different capitalization in the same sections of code anyway. “Did I mean to use $AGE, $Age, or $age here?” God forbid someone come through to enforce standards or something and fuck that all up.
But should $Age return the same value as $age if used in its place by mistake?
you really shouldn’t be using variables with the same name but different capitalization in the same sections of code anyway.
It’s a standard convention. Notice step #3 here: https://scottlilly.com/learn-c-by-building-a-simple-rpg-index/lesson-08-1-setting-properties-with-a-class-constructor/
Edit: Step #4 is a different standard convention that also applies here.
This is one case where I think Windows is appropriately designed for its target audience.
I don’t really see the benefit of allowing users to create files with the same name in the same directory, yeah, yeah I know that case sensitivity means that it isn’t same name, but imagine talking to a user, guiding them to open the file /tmp/doc/File and they open /tmp/doc/file instead
The reason, I suspect, is fundamentally because there’s no relationship between the uppercase and lowercase characters unless someone goes out of their way to create it. That requires that the filesystem contain knowledge of the alphabet, which might work if all you wanted was to handle ASCII in American English, but isn’t good for a system which needs to support the whole world.
In fact, the UNIX filesystem isn’t ASCII. It’s also not unicode. UNIX uses arbitrary byte strings, with special significance given to a very small number of bytes (just ‘/’ and ‘\0’, I think). That means people are free to label files in whatever way they like, and their terminals or other applications are free to render them in whatever way seems appropriate, without the filesystem having to understand unicode.
Adding case insensitivity would therefore actually be significant and unnecessary complexity to add to the filesystem drivers, and we’d probably take a big step backwards in support for other languages
macOS also does this by default, but you can change it (though you have to reformat the disk in question). This is generally fine for non-system disks if you REALLY need it for some reason, but afaik it is not recommended for the OS disk due to assumptions that macOS-targeted binaries make (similar to the windows regex version matching that caused problems for a while because it became the unofficial best way to check windows versions for app install compatibility). It’s doubly annoying on newer Apple systems because the integrated SSDs are WAY faster than pretty much anything else you can connect to it. But for the most part, I find it’s more of a nuisance to keep in mind than a real problem (I’ve been dealing with dev-issue MBPs since about 2012).
As in the windows case, this is also an appropriate choice for the average Apple user (though the fact that they’re fairly ubiquitous as dev machines in many places is annoying on several levels, despite the generally solid best-case performance and thermals I’ve observed).
Huh I had thought case-sensitive was default on APFS/HPFS and you had to choose insensitive specifically but I guess not
Just checked on my work box - if you go into Disk Utility and start the process to add a volume, the default selection is
APFS, and there’s an option in the dropdown for forAPFS (Case-sensitive)
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.
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.On the other hand in using Linux I have had a number of problems with the casing of files: The number is 0
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 :)
Windows and NTFS support case sensitive filenames. The functionality is disabled for compatibility reasons.
