If you’re building a package manager and git-as-index seems appealing, look at Cargo, Homebrew, CocoaPods, vcpkg, Go. They all had to build workarounds as they grew, causing pain for users and maintainers. The pull request workflow is nice. The version history is nice. You will hit the same walls they did.
↫ Andrew Nesbitt
It’s wild to read some of these stories. I can’t believe CocoaPods had 16000 directories contained in a single directory, which is absolutely bananas when you know how git actually works. Then there’s the issue that git is case-sensitive, as any proper file system should be, which causes major headaches on Windows and macOS, which are dumb and are case-insensitive. Even Windows’ path length limits, inherited from DOS, cause problems with git. There just so many problems with using git for a package managers’ database.
The basic gist is that git is not a database, and shouldn’t be used as such. It’s incredulous to me that seasoned developers would opt for “solutions” like this.
Yes, users trying to copy files from a case sensitive drive to FAT drives like SD cards is gonna go so well
Other than the preferences of niche Unix nerds, not quite sure what changing windows or macOS to this approach would actually accomplish for most users. Maybe someone can enlighten me on a practical use case for this change.
(Yes, I’m aware that macOS can be switched to case sensitive with a drive format. I don’t know any Mac users who have seen a need to do this…)
Er, it’s kind of the other way around: Windows and MacOS are (and always have been) Doing It Wrong. Case in strings conveys meaning, and an upper-case character is _not_ the same as a lower-case character. Deliberately _removing_ information from a filename string was obviously always a bad idea, especially when Unix was a pre-existing counter-example. And FAT is a DOS/Windows artifact.
This is one of the (many) reasons why, when I found out that my most recent employer was providing me with a Windows laptop, my first move was to install WSL2 and do precisely none of my development in native Windows.
That’s cool from a history perspective. The fact is that FAT storage is widely used, across all OS’. Arguing for a consumer-unfriendly option based on computing history isn’t particularly useful.
You can still use both cases. What you can’t do is have File, file and filE in the same directory. I do development too, and I’ve never once ran into this as a real, practical issue. Once you drop into terminal on a Mac, case is respected aside from the use case mentioned above.
My request was for a practical use case, aside from “well Unix did it better”. Your answer didn’t contain one. It can basically be summed up as “Unix did this right, and therefore I need to develop on Linux”.
Also, a practical use case that would justify the potential confusion for consumers would be nice.
Ask Dick how he feels about case sensitivity in file systems. Or Rose. Or ask the Germans, where nouns are capitalized and as such, case can change meaning considerably. In fact, every language that uses capital letters in some form has countless examples of case changing meaning considerably. Just because you don’t know enough about language to be aware of such cases does not mean we have to dumb down language to reach your level.
Case preservation != case sensitivity.
What you’re arguing for is case preservation. Nobody is arguing against that. What some people are arguing for is case insensitivity while preserving case.
Case sensitivity is simpler to implement in a world of Unicode. But case insensitivity is what most people expect. Some people prefer technical simplicity, other people prefer simplicity for the user..
Thom Holwerda,
The thing is case insensitive file systems generally do preserve letter casing. File system case sensitivity comes into play in determining index collisions. I think reasonable people can come to different conclusions over whether “rose” should collide with “Rose”.
For what it’s worth I think this criticism carries more weight against case non-preserving systems. A notable example of this is actually OSnews URLs and many wordpress sites more broadly. Notice how the entire URL gets lower cased with all upper case letters being replaced with lower case ones. IMHO this is not only a bad practice, but it’s particularly pointless given that this textual part of the URL is not even used to locating the resource. This scheme sacrifices upper case letters in what is intended to be a friendly URL for no technical benefit whatsoever..
Out of curiosity I looked up your two specific examples of “Dick” and “Rose”, and coincidentally OSnews has URLs where both of these names get improperly cased.
https://www.osnews.com/story/143184/dick-picks-unique-database-operating-system/
https://www.osnews.com/story/251/the-charlie-rose-interview-linus-torvalds/
Most users don’t care about case sensitivity. But choosing to ignore case in the filesystem opens the door to a host of possible problems you could just not have had. It’s Postel’s Law: be liberal in what you accept (though with filesystems, if you’re going to accept something you can’t “be conservative in what you do” in this regard). A case sensitive filesystem can store DOS games without issues. A case insensitive filesystem will run into issues cloning a git repo with case collisions. As a parallel, would you use a filesystem that didn’t allow periods in filenames, except to denote a file extension?
Also, trying to figure out Unicode casing rules in filesystem code, across different filesystems, with a Unicode standard that keeps evolving, sounds like a nightmare to me.
I will never understand why a filesystem should be case sensitive. What is the point? Makes no sense, at all.
Because a and A are different characters and should be treated as such. It is case insensitivity which makes no sense, and requires extra resources to implement since you have to convert everything to uppercase before you can do a string comparison etc.
Note that DOS/FAT was not case insensitive to start with, it only supported upper case and had no support for lower case at all.
Delirious. You should be able to use Upper and Lower case to make it simpler to read, but we don’t speak in “case sensitive”, nor should the filesystem be case sensitive.
Case-sensitive filenames are unfriendly and unintuitive for lamers and annoying for power users. There is no reason other OSes should be burdened with this problem too.
Minuous,
I agree, although I think both opinions are legitimate depending on use cases. Some may benefit from case sensitivity and others may not. Case insensitive file systems generally preserve letter case. The case insensitivity aspect is only in regards to detecting index duplicates and not case preservation. Personally I do not want multiple files of the same base name differing by letter case only, but some people feel differently.
We have the exact same dilemma in databases: should keys containing different letter cases by unique? As an experiment just now I tried registering “minuous” “alfMan” “thom_holwerda” to which osnews replied…
The osnews accounts are case insensitive and so these were considered dups, which IMHO is the right way to go. Had osnews used case sensitivity instead, these logins would have been unique. Is there anyone here who thinks case sensitivity would have been better? If not then I think we should acknowledge that the merits of case sensitivity depends on specific use cases.
Filesystems are hostile and unintuitive, and there is no reason people should be burdened by the problem of interacting with a filesystem. People will normalize all sorts of bad behavior.
It’s hyperbola, but yeah, most people would be better served if they didn’t need to interact with a filesystem. I have seen what people do when given free reign, and it’s always some shade of bad. I can’t manage my files either, so I’m not excluded.
Flatland_Spider,
For better or worse, file systems are fundamental and unavoidable to lots of real work. Even platforms like iphone that tried to do away with them resulted in a gimped experience full of ugly hacks and they ended up re-deriving the file system primitives for users.
https://en.wikipedia.org/wiki/Files_(Apple)
Clearly tools can be abused and we have plenty of examples. Still, it is objectively far worse to not have them when you need them than to have them when you don’t.
Maybe someone should build an indexing system with delta support.
Or use gzipped metadata files; Arch, Debian and other don’t seem to have an issue with it.