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 :)
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
No, I’m arguing that the extra complexity is something to avoid because it creates new attack surfaces, new opportunities for bugs, and is very unlikely to accurately deal with all of the edge cases.
Especially when you consider that the behaviour we have was established way before there even was a unicode standard which could have been applied, and when the alternative you want isn’t unambiguously better than what it does now.
“What is language” is a far more insightful question than you clearly intended, because our collective best answer to that question right now is the unicode standard, and even that’s not perfect. Making the very core of the filesystem have to deal with that is a can of worms which a competent engineer wouldn’t open without very good reason, and at best I’m seeing a weak and subjective reason here.
because it creates new attack surfaces, new opportunities for bugs, and is very unlikely to accurately deal with all of the edge cases.
Unicode case folding has been a solved problem for a long time. The Unicode standard has rules for which characters should be considered identical, and many libraries exist to handle it (you wouldn’t ever code this yourself).
Well you’re just asking an economic question, are the costs worth the benefits?
I’d argue that linux will never be a good or user friendly operating system without case insensitive filenames.
That isn’t an opinion but could be verified through scientific study of how confused people act. You don’t even need computers, just ask someone to get the “something SomeTHing” from a labeled box in a cupboard. Presumably science would show that case insensitive naming of things is always less confusing when humans actually use the system.
The truth is that programmers enjoy writing code far more than reading code. And especially to open source developers “usability” is a dirty word. It’s not about the value of a thing, it’s about the beauty of how it is done.
Let’s say you have a software that generates randomly named files, having the ability to use both upper case and lower case means you can have more files with the same amount of characters, but that sounds horrible and it’s the only thing I can think of atm
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).
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 for APFS (Case-sensitive)
This is one case where I think Windows is appropriately designed for its target audience.
This isn’t “Windows design”… this is just inherited stone age bullshit.
This isn’t just a Windows thing… It’s the same on MacOS by default.
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
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 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
You’re basically arguing that a system shouldn’t support user friendly things because that would add significant burden to the programmer.
The quintessential linux philosophy. Well done! I mean, what is language? Why have named code variables? This is just a random array of bytes!
No, I’m arguing that the extra complexity is something to avoid because it creates new attack surfaces, new opportunities for bugs, and is very unlikely to accurately deal with all of the edge cases.
Especially when you consider that the behaviour we have was established way before there even was a unicode standard which could have been applied, and when the alternative you want isn’t unambiguously better than what it does now.
“What is language” is a far more insightful question than you clearly intended, because our collective best answer to that question right now is the unicode standard, and even that’s not perfect. Making the very core of the filesystem have to deal with that is a can of worms which a competent engineer wouldn’t open without very good reason, and at best I’m seeing a weak and subjective reason here.
Unicode case folding has been a solved problem for a long time. The Unicode standard has rules for which characters should be considered identical, and many libraries exist to handle it (you wouldn’t ever code this yourself).
Well you’re just asking an economic question, are the costs worth the benefits?
I’d argue that linux will never be a good or user friendly operating system without case insensitive filenames.
That isn’t an opinion but could be verified through scientific study of how confused people act. You don’t even need computers, just ask someone to get the “something SomeTHing” from a labeled box in a cupboard. Presumably science would show that case insensitive naming of things is always less confusing when humans actually use the system.
The truth is that programmers enjoy writing code far more than reading code. And especially to open source developers “usability” is a dirty word. It’s not about the value of a thing, it’s about the beauty of how it is done.
Oh, I realize why it is, I just don’t see it as an advantage, the whole argument is just a technical one, not a usabillity one.
pov: you encode filenames in utf-1, just happens to contain one of those bytes
Idiot user! ;)
Let’s say you have a software that generates randomly named files, having the ability to use both upper case and lower case means you can have more files with the same amount of characters, but that sounds horrible and it’s the only thing I can think of atm
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)