Does this also work in Linux or just GNU/Linux?
Or as I’ve recently taken to calling it, GNU+Linux
This makes installing Skyrim mods harder because mods often contain differing versions of folder names. For example one mod might be “Scripts” and the other might be “scripts”. This means you can’t have Skyrim mods on Linux if you’re allergic to copying files manually as this will generally make mod managers not work as well. People on forums like nexus have a hard time even grasping the concept of not using a mod manager so it’s hard to get help of any kind.
Chadman would never say brrrrrrr
Windows way is superior, in my opinion. I don’t think there’s a need for File.txt and fILE.txt
FlLE.txt FILE.txt
Indeed. Linux audio allows control characters like backspace to be part of a file name (though it is harder to make such file as you can’t just type the name). Which is just horrible.
Linux audio?
Yeah, Linux can capture and playback the spoken distinction between lowercase and uppercase letters. Windows can’t do that.
You’re not taking advantage of that functionality?
I sense sarcasm but I don’t really get it. I still can’t tell if the OC had a typo or not :)
: D
I think they just fixed it
I was so curious if there was some weird Linux audio system I didn’t begin to understand lol
It sounded plausible kind of because every device is mapped to a file path somewhere!
:D.
Fixed
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.
fandFare not the same ASCII or UTF-8 character, so why would a file system treat them the same?Having a direct
chartype to filename mapping, without unnecessary hocus pocus in between, is the simple and elegant solution.so why would a file system treat them the same?
Because it’s designed for average people, not bots. Imagine the headache of telling people to add a line in file.txt, but they misunderstood and add it to File.txt
Furthermore, I personally cannot think of any use case for having files with the same names reside in the same directory. It would just create confusion even among tech savvy users and programmers
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?
for all purposes
Different words that say the same thing…
Anyway, even for those automated processes, there’s no good reason to use files with the same names in the same directory, it’s bad practice and adds unnecessary confusion in the design of the code.
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.
If you don’t do something stupid like reuse keys just with different capitalization, this never occurs.
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.
It turns out that the easiest thing to program isn’t always the best application design.
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 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 in filenames as well.
That’s some suckless level cope. What’s correct is the way that creates the least friction for the end users. Who really cares about some programming purity aspect?
Strictly speaking, this is a limitation of the default filesystem, and not the core operating system. If you mount a NFS share that is case sensitive, it will still be case sensitive.
Technically not a limit there either since you in windows on NTFS can set a flag on a folder to make it case sensitive
fsutil.exe file queryCaseSensitiveInfo <path>
you can also use basically anything that’s not / in a file name as well, it’s pretty based. Meanwhile on windows you have to use SMB mappings if you don’t want your directory structure to self immolate, what a good operating system.
I recently renamed a few movie files to something with ‘:’. That worked fine on Linux, but lead to some issues on windows. With a lot of errors from next cloud for file sync and me not being able to rename them without booting back to Linux. Fun stuff
That’s a great feature, actually, it saves you from using Windows
I think you might even be able to get away with /s if you escape them properly in the filename.
i’m not sure if you’re allowed to escape the / character, i feel like it’s blatantly illegal. But you could use the funny character set trolling thing instead, where you use a not forward slash instead. (not the \)
I’m fairly confident MacOS allows it, I’ve seen people do some Utterly Cursed shit in MacOS, but idk about Linux
maybe on macos, that might be funny, it’s probably fucky over there for some other reason anyway.
Im pretty sure it’s just explicitly illegal in linux though.
Just tried. It processes the escape first and then finds the path with it. Essentially, making it look into a directory made by the characters before the
\/.The above was when I tried:
echo "asd" > asd\/dsaBut then I tried using Dolphin (GUI File Browser) to make a file and:
❯ ls 1 2 3 4 'asd\⁄sad.txt' ❯ ls 1 2 3 4 asd⁄sad.txtIn the first one, the backslash is not the escape character, but part of the text.
HEY, NOT ALL OF US CAN AFFORD LOWER-CASE LETTERS
Is it just me or is that more of a hinderance?
Definitely an inconvenient thing.
I absolutely fail to see the utility of having a user called Bob and bob, or a dir called Downloads and downloads. Capitalisation makes sense in code - at a glance I can know I’m looking at a Class or a var, but for system administration it has only ever wasted time, and not once made anything easier.
Yeah
The main problem with case-insensitive is that software sometimes is lazily developed: If a file is named “File.txt” and a program opens “file.txt”, then on a case-insensitive file system it will work fine. If you then format your drive to case-sensitive, the same software now fails to load the file. Source: tried case-sensitive filesystem on macOS some years ago.
Its given me issues installing the Fallout 2 Restoration patch.
Had this issue with Full Tilt! installer on Wine, fortunately the fix was easy
I can make a file named COM1 on Linux. That’s on the forbidden list for Windows.
The forbidden list:
- CON
- PRN
- AUX
- CLOCK$
- NUL
- COM1
- COM2
- COM3
- COM4
- COM5
- COM6
- COM7
- COM8
- COM9
- LPT1
- LPT2
- LPT3
- LPT4
- LPT5
- LPT6
- LPT7
- LPT8
- LPT9
Windows users can’t even download PRN from the interwebz? Pathetic.
That’s because Windows is generally very backwards compatible.
So is Linux, but it puts stuff like that in /dev
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.
It still amazes me how well thought out unix was for the era when computing was in its infancy. But I guess that is what you get with computer science nerds from Universities and a budget for development based on making a product the goal, not quarterly profit the goal.
It’s what you get when you design an OS for a mainframe computer that is accessed by many users sharing its resources.
DOS was designed for single-user PC’s with very limited processing power, memory and storage, and no access to networked drives. Lots of its hacks and limitations saved a few hundred bytes of memory, which was crucial at the time.I guess i was meaning compared to DOS but modern Windows, where stupid stuff is broken, and they care more about ads than creating a clean OS
Unix was designed for mainframes, qdos/msdos was designed to be a cpm knockoff the local nerd could use to play commander keen and do his taxes. It’s actually impressive how much modern/business functionality they were able to cram into that.
Unix was designed for mainframes
Unix was never for mainframes. It was for 16-bit minicomputers that sat below mainframes, but yes they were more advanced than the first personal computers.
It’s actually impressive how much modern/business functionality they were able to cram into that.
Absolutely, but you have to admit that it’s a less solid foundation to build a modern operating system on.
In the 80s, there were several Unices for PC too btw: AT&T, SCO, even Microsoft’s own Xenix. Most of them were prohibitively expensive though.
LPT1 LPT2 LPT3 LPT4 LPT5 LPT6 LPT7 LPT8 LPT9
Why does Microsoft hate Life Pro Top listicles?
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.
oh no, but com5 is one of my favorite words! literally unusable.
Oh it’s even better, windows explorer can’t really do case sensitive
But NTFS is a case sensitive file system
This occasionally manifests in mind boggling problems
Yeah, it’s super weird. I once named a file with mixed case, but one of the letters was the wrong case. Renaming the file didn’t work at first. Renaming a file named PAscalCase.txt to PascalCase.txt resulted in no change to the filename. Windows continued to show it as PAscalCase.txt. I had to rename it to something totally different with different characters entirely, then rename it again to get it right.
Renaming it in Explorer does actually rename the file if all you change is the case, but whatever mechanism Explorer uses to determine “has this file’s name changed” is apparently case insensitive. So it won’t refresh the file list. (I imagine this is yet another one of those damn fool Windows 95 holdovers, or something.)
You don’t have to do any multiple-renaming jiggery pokery. Just press F5 to refresh that Explorer window and magically then it’ll show you that the file’s name was indeed changed all along.
Nope. Tried that. Tried DIR in a command window too. But I never specified even what version of Windows I was running, so I’m a little unclear why you’re trying to troubleshoot a problem I was experiencing on windows nearly a decade ago. I guess this is what be mansplained too feels like.
NTFS is case insensitive because it’s supposed to be more POSIX compatible than its precursors.
You can enable case sensitivity in windows. It’s only disabled by default.
I wouldn’t do it though. It can only lead to problems, especially with poorly coded programs.
I find it really fucking irritating on Linux tbh. It knew what file I meant.
Yeah as someone who uses both this is really not much of a feature.
It’s a lack of a feature really. Case insensitivity takes way more work.
Case-sensitive is easier to implement; it’s just a string of bytes. Case-insensitive requires a lot of code to get right, since it has to interpret symbols that make sense to humans. So, something over wondered about:
That’s not hard for ASCII, but what about Unicode? Is the precomposed ç treated the same lexically and by the API as Latin capital letter c + combining cedilla? Does the OS normalize all of one form to the other? Is ß the same as SS? What about alternate glyphs, like half width or full width forms? Is it i18n-sensitive, so that, say, E and É are treated the same in French localization? Are Katakana and Hiragana characters equivalent?
I dunno, as a long-time Unix and Linux user, I haven’t tried these things, but it seems odd to me to build a set of character equivalences into the filesystem code, unless you’re going to do do all of them. (But then, they’re idiosyncratic and may conflict between languages, like how ö is its letter in the Swedish alphabet.)
Yeah the us defaultism really shows here.
This thread is giving me flashbacks to the times before Unicode, when swapping files between Windows and Linux partitions would have a good chance of fucking up every non-ASCII characters in their names.
There was ways to set it up so the ISO character sets would match, but it was still a giant pain to deal with different ones.
Blessed be Unicode.
A related issue I still see very often, even with files newly created just this year, is when trying to extract zip files on my Linux systems that contain non-ASCII filenames and that were created on Windows systems, especially ones with apparently non-English locales like Japanese. Need to trial and error the locale I give to unzip and sometimes hack together fixed names with iconv until the mojibake seems to fix itself.
cd downloads
bash: cd: downloads: No such file or directory
cd Downloads
user@pcname:~/Downloads$
Bash has an option for that you can put in your
.bashrc:bind "set completion-ignore-case on"Zsh autocompletes lowercase input to the correct file or folder name when using tab. It’s great!
Fish does this too, it’s super convenient
Fun things happen whenever you upload 2 files with the same names, but differently capitalized letters to a Nas from a linux box, and then try to delete one of them from windows. It broke so hard I actually got a bsod…
