Windows way is superior, in my opinion. I don’t think there’s a need for File.txt and fILE.txt
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.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?
That’s some suckless level cope
Thanks, really constructive way of arguing your point…
Who really cares about some programming purity aspect?
People who create operating systems and file systems, or programs that interface with those should, because behind every computing aspect is still a physical reality of how that data is structured and stored.
What’s correct is the way that creates the least friction for the end users
Treating different characters as different characters is objectively the most correct and predictable way. Case has meaning, both in natural language as well as in almost anything computer related, so users should be allowed to express case canonically in filenames as well. If you were never exposed to a case insensitive filesystem first, you would find case sensitive the most natural way. Give end users some credit, it’s really not rocket science to understand that
fandFare not the same, most people handle this “mindblowing” concept just fine.Also the reason Microsoft made NTFS case insensitive by default was not because of “user friction” but because of backwards compatibility with MSDOS FAT16 all upper case 8.3 file names. However, when they created a new file system for the cloud, Azure Blob Storage, guess what: they made it case sensitive.
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
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.
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.
surely Git warns about stuff like this when you clone it, right ?
It tells you there’s a name clash, and then it clones it anyway and you end up with the contents of
README.MDinREADME.mdas an unstaged change.sounds like actually a good solution … tho doesnt sound like it would work for more than 2 similarly-named files
I don’t think it’s intended as a “solution”, it just lets the clobbering that is caused by the case insensitiveness happen.
So git just goes:
- checkout content of README.md to README.md (OS creates README.md)
- checkout content of README.MD to README.MD (OS overwrites README.md)
If you add a third or fourth file … it would just continue, and file gets checked out first gets the filename and whichever file gets checked out last, gets the content.
