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.

#if JUCE_LINUX
 #define NAMES_ARE_CASE_SENSITIVE 1
#endif

bool File::areFileNamesCaseSensitive()
{
   #if NAMES_ARE_CASE_SENSITIVE
    return true;
   #else
    return false;
   #endif
}
3 Likes

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.

3 Likes

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…