File::findChildFiles wildcard is case sensitive

On Linux with JUCE 7 File::findChildFiles is case-sensitive. A user reported that this was not the case in the past.

In macOS and Windows it shows test.WAV files when the wildcard *.wav is set. On Linux the test.WAV file does not show up.

Is this a bug or do I miss something?

Is it possible your user is misremembering? A quick review of the relevant source (juce_File.cpp) indicates that the current behavior has been the case for quite a long time. There is a compile time constant that controls this, and as you can see in GIT, it hasn’t changed in a while. Checking the corresponding code where it is used also yields no recent changes.

The product exists already 7 years. I’m not sure :slight_smile:

I wonder why the behavior is not the same on macOS and Linux. Both systems are case-sensitive. Does it make sense to overwrite the NAMES_ARE_CASE_SENSITIVE 0 and set it to in the CMkake file or is this dangerous?

Mac is not case sensitive by default. oh, except for command line tools… eh, so much for consistency!

1 Like

That is NOT true. It solely depends on the file system. By default, on macOS, the file system is case-aware but not case-sensitive. So you can change the capitalization, and it will be displayed correctly, but the case doesn’t matter for finding the files.

Windows, for example, only offers a case-aware but no cases sensitive file system. To me, that’s the only sane way. We humans tend to make mistakes, so we always mistype stuff. Should the computer refuse to load/find the file because of such a silly mistake? Of course not. Imagine an article’s author miscapitalizing a word by accident, and now your brain refuses to see that word. Wouldn’t that be highly inconvenient, confusing, and outright stupid?

Why should the OS refuse to load the file “test.wav”, if it’s called “Test.wav”? Isn’t allowing two files with identical names but different capitalizations in the same directory confusing? So I can have 20 variations of test.wav? Surely that’s not confusing and prone to errors at all!

NTFS is case-sensitive Case Sensitivity | Microsoft Learn

Thanks for the answers. I grew up with windows and I like the way windows handle filenames. I also think it is a great feature to ignore the case for filenames and folders.
I often end with an all-lowercase solution for filenames and folders on UNIX systems just to simplify things…
Looks like I need to accept that on Linux we can’t load a *.WAV or *.Wav file because the wildcard does not match with *.wav.

Thank you for letting me know how the OS works I’ve been using since 1995.

By default NTFS is case aware, but not case sensitive. Since Windows 95 came out, I’ve not encountered a single user, customer, or programmer, who was aware it can be configured that way or having done so. For all practical purposes the option might as well not exist.

Only around 1% of our customers configured their macOS drives to be case sensitive, and only because they weren’t aware of the consequences.

Congrats. You’re right on a technical level. Pat yourself on the shoulder.

1 Like

You’re welcome:)

Windows 95 with it’s FAT32 was not case-sensitive in any way. NTFS (formerly HPFS) was able to be case-sensitive since it’s beginning. Windows NT has POSIX-compatible API for that, which can be used with cygwin, for example.

As a productive user of case-sensitive file systems (they are important!) I would just like to say that the snark is not really necessary - this is a complicated scenario and we as programmers need to deal with the edge cases, even if we ourselves have not encountered them in our experiences so far …

Case-sensitive filesystems have their productive uses. It serves no purpose to attempt to degrade their use. Find out if your users’ filesystem is case-sensitive (static bool File::areFileNamesCaseSensitive()), and adjust your code accordingly. Some of us rely on it.


perhaps inconerCase might help JUCE: String Class Reference

1 Like

That function is the biggest crock I’ve ever seen. It doesn’t query the OS to test, it simply makes bad assumptions and returns a potentially wrong result. It has a 50% chance of being right. It might as well return a random bool.

1 Like

Would you enlighten us what those uses may be?

Massive (terabytes) Document and Media Databases, for one.

We have a studio case-sensitive fileserver full of decades worth of projects. It guarantees we never, ever overwrite anything just because a junior producer had his CAPS LOCK key on … Anyway its my decision to make about my environment, not yours. If you put more energy into trying to convince me otherwise than you would just programming a solution for your end-users, then you might not see why its important at all …

This is an interesting discussion. Such decisions are always a compromise. For me, it is small things like this that make Linux a pain for a normal end user.

On the Web, we even find results when we make spelling errors. Think that’s the way we should also handle file searches in the future.

If there is a case for either way (and it seems that way to me), then it needs to be configurable.
IMHO it should be a parameter to findChildFiles:

enum class SearchType
    Auto=0,           // depends on the file system