More precisely, they came up in a time where Unicode was not a thing.
Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
They don’t. None of them.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? […] Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
Because you cannot have both.
It is either “spaces, cyrillic, special characters and long names” or case insensitivity.
OK, you’re going to have to be specific about your technical claims here. Which part of unicode support on filenames prevents case insensitive filenames?
I mean, I don’t know why you made me try, because I do use non-English characters day to day. But you made me try, and sure enough, you can absolutely mix and match alphabets and cases in NTFS and still have it behave case-insensitively. i.e. делоinsensitive.txt and делоINSENSITIVE.txt can’t be placed in the same folder and are parsed as the same name.
So if you have some bit of nuance about why you “cannot have” the feature that clearly works right now in front of me in my computer and has for ages I’m all ears. For a completely impossible implementation of a clearly useful feature it sure seems like it is actively supported in most of the FSs currently in use.
EDIT: Made me go check because now I’m curious about the edge cases you guys keep claiming are catastrophic. Putting those two files in a case sensitive Samba share an opening it in Windows keeps the mix of characters but a suffix gets unceremoniously appended to the filename of one of the files. That’s probably a bit of a mess in some circumstances if you don’t know it’s coming, but there you go.
Ah. So this functional feature is not actually functioning, I just see it function because I’m too dumb to understand all the ways it’s not actually doing the thing it’s doing.
More precisely, they came up in a time where Unicode was not a thing.
They don’t. None of them.
Because you cannot have both.
It is either “spaces, cyrillic, special characters and long names” or case insensitivity.
OK, you’re going to have to be specific about your technical claims here. Which part of unicode support on filenames prevents case insensitive filenames?
I mean, I don’t know why you made me try, because I do use non-English characters day to day. But you made me try, and sure enough, you can absolutely mix and match alphabets and cases in NTFS and still have it behave case-insensitively. i.e. делоinsensitive.txt and делоINSENSITIVE.txt can’t be placed in the same folder and are parsed as the same name.
So if you have some bit of nuance about why you “cannot have” the feature that clearly works right now in front of me in my computer and has for ages I’m all ears. For a completely impossible implementation of a clearly useful feature it sure seems like it is actively supported in most of the FSs currently in use.
EDIT: Made me go check because now I’m curious about the edge cases you guys keep claiming are catastrophic. Putting those two files in a case sensitive Samba share an opening it in Windows keeps the mix of characters but a suffix gets unceremoniously appended to the filename of one of the files. That’s probably a bit of a mess in some circumstances if you don’t know it’s coming, but there you go.
No, I’m not going to waste further time on trying to make you understand things you are not capable or interested in understanding.
Ah. So this functional feature is not actually functioning, I just see it function because I’m too dumb to understand all the ways it’s not actually doing the thing it’s doing.
Gotcha.
Exactly.
Persuasive.
So anyway, this here, kids, is why you don’t ever let software engineers actually design functionality for end users.
Just go away.
Don’t think I will.
Case insensitive is still the right choice, too.
I hope you get the help you need.