BR: File::areFileNamesCaseSensitive() returns the wrong result

macOS can have case sensitive file systems. This really shouldn’t be a static function, it should check if the file is on a case sensitive file system or not. As well, Linux could have a FAT32 filesystem mounted.


bool File::areFileNamesCaseSensitive()
    return true;
    return false;

This is actually not just for macOS and Linux - believe it or not, Windows can be configured to be case sensitve (it’s a new thing starting from Win10).

…and later mac installations are no onger case sensitive. Seems this needs to check the file system, a platform define doesn’t seem to work here.

1 Like

This is an NTFS file system feature that you can enable on a per-directory basis.

The case sensitivity flag only affects the specific folder to which you apply it. It isn’t automatically inherited by that folder’s subfolders.

Linux tools you run inside the Windows Subsystem for Linux (Bash shell) now create folders with the case sensitive flag set. So, whether you use the mkdir command to create a directory inside a Bash shell or a development tool does it for you, the created directory is automatically set as case sensitive—even if you create it on your mounted Windows file system.

Oh this sounds like fun.


The more I think about this, the harder and more complex the issue really is: when writing files/folders to a volume/disk, you need to check the format of that target disk in order to determine if its case-sensitve to even get close to finding out if the file/folder/path already exists or not…

Would it be possible (and easier) to just force JUCE to always pretend things are case-sensitive? Not sure what the pitfalls of doing that would be off the top of my head.

I’m aware of the FILE_FLAG_POSIX_SEMANTICS for the Win32 file APIs which could be of help…