Depends on the application I would think. If they do everything properly, they should let the file system handle it and not care themselves about case-sensitivity.

The problems start whenever a program asks the user for a file name and it then saves that raw users input.

For example lets imagine some sort of batch processing application that runs user defined scripts.

To define some batch process, the user provides the name the script to be run, so they enter 'MyScript.py' even though the file lives on disk as the 'myscript.py' file.

That batch processing application then saves the user supplied file name 'as is' and everything works fine in default Windows file system mode.

However, flipping that file system option to make it case sensitive suddenly the batch processing will fail.

As Windows applications don't have to deal with case sensitivity, they don't do things like check if the user has entered the name correctly in terms of case.

The just ask the file system if the file exists and likewise, Windows is not checking the case when it does that 'exists' check.

> The just ask the file system if the file exists and likewise, Windows is not checking the case when it does that 'exists' check.

I haven’t tried it, but I would assume that’s exactly what happens. The file system, with the case-sensitive flag, should return "File does not exist".

Yeah, I just tested this, works exactly as expected. After creating `Hallo.txt` and calling `File.Exists(@"C:\folder\hallo.txt")`, I get `false` with the attribute enabled, and `true` with it disabled

key being "properly". Many programs, especially games, fail under wine because of case sensitiveness and need workarounds.

That’s a different problem though. It sounds like that’s programs calling Name.xyz when the file is called name.xyz

That’s probably also the reason why there is no direct way to enables case-sensitivity recursively ;)