macOS fuckup continued. Today I used a camelcase name for some new file and a directory. Later I didn't like it and wanted to change to lowercase. Pushed it to bitbucket: now I had both versions! Hold my goji berries, what's going on? Maybe some git config screw up? After a bit of fiddling I remembered an old Linus' rant on Apple's file system when they wanted to adopt case insensitivity. So wait, did they actually do that shit? I thought I was on a unixoid, bastardized BSDish system, that apart from all the oddities that Apple bestowed on it, that there was still some sanity left... But, no there isn't. AFP really defaults to case insensitivity.
I have no words.
So switched to my Debian, where I resolved the duplication in two secs. Now Linux feels even much more comfy and home.

Haha, just like Windows, even though 10 provides an option to make it case sensitive

@asgs 10 can use case sensitve?

@asgs you can opt out there as well... But change the file system options just to fix a git commit?
There's also some weird compatibility mode for iOS and other friggin complexities you just wouldn't have if you hadn't started with case insensitivity:
https://developer.apple.com/library...
(isn't readable on mobile 👍)

This might be unpopular, but still...
So, computers are tools to serve us. As such, they should adapt to our needs rather than the other way round.
If I call my coworker "HEY ALEX" he might look at me a little odd because I never shout, but he'd never think "nope, not me, my name's 'Alex' after all". Humans don't differentiate between that. And computers shouldn't either.
Case insensitive + preserving file systems are the right thing. The tool is working for me instead of against me. +1 for Apple and Microsoft from me.

brain... hurts.....

This is some oldass shit. Apple should have defaulted to case sensitive ages ago.

@stop yes, but it is opt-in

@phorkyas git commits and a whole lot of case sensitivity! After adjusting to Linux, it feels very weird if things like this work differently

@Haxk20 Can I please see that list? Pretty Please :pray:

@VaderNT Interesting, but yet I'd argue it's a total useless "abstraction", where you don't gain much. You should pick the right fights.

Let me tell how it continued: After corrected from Linux force pulled the branch on Mac. Only one directory and file. Fine. Then I edited this file. BANG, got two files again! Checked on the file system: They have the same inode. So somehow AFP is giving aliases for the same thing, and it is keeping track of which aliases you already used?

Yes, and this machinery is only there to make things "easier" for you. Thanks. I'd prefer to be in control, that the OS just does what I *want*. Not that it pops up that useless alias, I wanted to get rid of. I'd prefer to know if the file system is yelling at me: "DONT_TOUCH_THIS_FILE" or it is not...

(I know, more an interoperability issue and what you are accustomed to,... but just imagine the thousands LOC in the file system and the amount of bugs produced. Should tell you it's the wrong abstraction)

@Haxk20 only 12k?

man, you didn't do your homework, bruh...

I had to make it in SQL becouse .txt editors couldn't handle the load, and eventually overflown my terabyte hard disk with that db... ;-;

@Haxk20 Oke, let's stop before some apple fanboi gets hurt in his emotions about his fav company and starts rage flame warfare ;)

But yeah lists are really really long.

Case sensitivity is actually nonsense for a file system. Nobody wants Example.txt, example.txt, eXample.txt and example.tXt to be different data.

On the other hand, case insensitivity is impossible to get right because the definition of what case even is depends on the locale. Upper case i is I in English, but in Turkish, it's İ.

@phorkyas and I'd argue the other way round - that readme.txt and ReadMe.txt are different files to the computer is a useless detail.
In any case, the behavior that you described is plain weird. Were you able to solve it?

@VaderNT /VADERNT @Fast-Nop /FAST-NOP Have fun: https://devblogs.microsoft.com/oldn... - or well before you'd have to decide if you do case folding, case mapping or case normalization *shoot me* -

Or take these nice properties:

* "Case mappings may produce strings of different length than the original"

* "Characters may have case mappings that depend on the locale"

(http://unicode.org/reports/tr21/... )

You really wanna do locale dependent lookups for every file system access through paths? Open the doors to all the quirks of human scripture systems?

- Maybe I should learn some "sane" Arabic or Mandarin..

Okay, I have a solution...

Dont allow characters not fitting in mask a-zA-Z0-9-_.+

When file exists (internally everything on str_to_lower) with other cases, treat as file duplicate etc.

You store cases in fs index/table, and every fs driver is clear to str_to_lower everything.

This should work, and isnt overcomplicated, and oh well, russian friends with cyrlic file names, tough shit.

Forgot the most important argument (which was a bit implicit before): If case sensitivity bears no meaning, it should have been abolished altogether. Maybe in English it is mostly a visual aid to find the beginning of a sentence, but for instance in German you can already distinguish nouns from the other word classes broadly speaking. E.g. "Weg" is a path while "weg" is "away", so case conveys semantic differences.

Why should it be a "useful abstraction" to take away this expressiveness, maybe as a user I want to be able to SHOUT or speak more silently within my file names?

@DubbaThony Sounds similar to what they are/were doing:

>In macOS High Sierra, APFS is normalization-insensitive in both the case-insensitive and case-sensitive variants, using a hash-based native normalization scheme. In iOS 11, APFS is normalization-insensitive as well, using either a native normalization scheme (erase restores only) or runtime normalization scheme (upgrades from previous versions). Runtime normalization will also be available in iOS 10.3.3 and macOS Sierra 10.12.6. Being normalization-insensitive ensures that normalization variants of a filename cannot be created in the same directory, and that a filename can be found with any of its normalization variants.

@phorkyas

Except that solution would allow easly renaming to other cases, and removing and adding with other case, which isnt the case for mac OS as we see OP complained about.

@DubbaThony you're kidding about the mySQL DB that overflowed a terabyte hard-disk right?

I'd seriously like a to see a good list of reasons not to use Apple products | cc : @Haxk20

@shine

Only valid use cases for apple products I personally accept:

- pushing to apple store that requires trusted machine (what the fuck apple? seriously? what kind of bullshit is this?)
- making music professionally.

@phorkyas there will always be corner cases. But Win and macOS already implement case insensitivity, so I consider these points moot tbh.

About weg/Weg: The point isn't that upper and lower case isn't useful. The point is that a word stays the same independent of case. "ICH BIN WEG" will be understood as "I AM GONE". Noone will scratch their head like "it should be 'weg', so that can't be it. It can also not be 'Weg' because it's completely in upper case. 'WEG' doesn't even exist in the dictionary, these words mean nothing!"
And there's still no upper and lower case in spoken German, because a word stays the same independent of writing.

A computer acts like words DIDN'T stay the same, and THAT isn't useful.

@VaderNT "And there's still no upper and lower case in spoken German,"

actually "Weg" and "weg" are even pronounced differently, one with a short "e". As you can also hear someone SHOUTING. Spoken language *has* this distinction, even many more registers and nuances a written text cannot reflect. Even with stupid emojis. Case insensitivity only takes away a little bit. Maybe it's insignificant,.. but if it's that insignificant I'd say it's not worth the effort. Many man month for THAT?

That Windows and macOS implement something doesn't justify it. Means it's somewhat feasible, but not that it's a good idea. People publish npm modules or webservices that do toUpperCase() /SHOUT EVERYTHING. Or write malware and all kind of horrible shit. Doesn't mean it's good.

@phorkyas If you had bothered to read the second paragraph of my comment instead of stopping after the first sentence, you might have noticed that I had already stated the locale example.

@phorkyas "actually "Weg" and "weg" are even pronounced differently"
You're missing the point. Different pronunciation doesn't matter, shouting doesn't matter, other nuances don't matter. You can write weg, Weg, wEg, weG, WEg, WeG, wEG, WEG and it's always the same word. Do these refer to noun "Weg" or adverb "weg"? Doesn't matter! You can spell both either way, it doesn't change the word.

"Case insensitivity only takes away a little bit."
You can call your file readme, ReadMe, README or any way to your heart's content. What does it take away? That you can't confuse people with both a ReAdMe and a rEaDmE?

"That Windows and macOS implement something doesn't justify it."
You're again missing the point. When people say case insensitive file systems can't be done, I point them to two instances where they were, in fact, done. Do they solve all problems with locale? No, as I said "there will always be corner cases".

@Fast-Nop had already seen that example in three other places, maybe that's why I skimmed a bit over it, but I read it. Some things I'll grant you:
that it might take a lot of cruft under the hood to convey sth seemingly simple to the user or increase the usability or ease of work.

If for you case insanity is such a thing, well. Can't change that.

@VaderNT Maybe there was some stubbornness on my side and I should not have continued the debate any further, because now I'm starting to get pissed.

Just stating that I miss the point, is not making a point and will only give zero points.

"Weg" and "weg" *are* different. Different word classes, different meaning. Maybe you want to hint at the point that natural language is full of ambiguities, in that case same representation for different things and that from the context we can always guess the right thing (until you take away too many cues and forum flame wars start!)

Maybe you remember these texts where they changed the order of many vowels and letters and one could still read it... So mbaye yuor flie sytsem shoudl also recongzie tihs?

..hmmm, actually maybe my shell should! Annoyed by how often I mistyped "git statsu" I already installed https://github.com/nvbn/thefuck - should try to use it. So enough of: https://xkcd.com/386/

@phorkyas Noone said "Weg" and "weg" are the same. To be clear:
Consider the concepts behind the words "Weg" and "weg". The concept of a path, and the concept of being gone. You can represent each in various ways - spoken, written, maybe painted.

Take the sentence "Ich bin weg" ("I am gone"). It uses the second concept ("being gone").
Now I change the representation a bit: "Ich Bin Weg". Did I change to the concept of a path? No! The concept behind the sentence is still exactly the same, I just chose a different _representation_.
This regards the direction concept -> representation. I can do the same to "Weg" and represent it as weg, ..., WEG. The concept I express is always the same, no matter the representation I choose. And that is what I was trying to explain in the first paragraph of my previous comment.

You mention the other way round, which is less clear, yes. No, I did't want to hint at that. We can still discuss this later, right now I believe you've ragequit the discussion.

@phorkyas It's okay to get angry and I commend you for being open about it. In return, let me share my own frustrations.
I'm mildly annoyed myself. You repeatedly argued against positions I do not hold, and I do not see where these interpretations come from. That's *frustrating*. I've been wondering: Haven't I been clear enough? Is there a language barrier between us? Might you be trolling me?

In all seriousness, some things are so far off the mark it's almost comical. Like ""Weg" and "weg" *are* different" - yes, yes indeed they are! Why on earth would I argue otherwise?

You may not like to be told to have misunderstood. From my POV it's... not one bit fun to see my discussion partner argue in a completely different direction. Not one bit.

Anyway, whether you've left the discussion or not, have a nice weekend.

@VaderNT Thanks for your patience! I somewhat ignited over the statement those things WERE the same, but while writing my heated response it dawned on me you just meant they were the same REPRESENTATION for different concepts.

I can understand your frustration, I was probably throwing some rhetoric and examples at you that felt far fetched.

(Somehow this topic reminded me of the unicode code points and that you can have different representations/encodings for them,.. but of course they don't allow for ambiguities...)