It appears that DirectoryIterator is malfunctioning with High Sierra’s new file system.
Our plugins’ Preset Menu loads an alphabetized list of presets using this function:
void UAPresetMenu::presetFolderConstructor(File &fileToSearch, PopupMenu &menuToPopulate, int &fileIndex)
DirectoryIterator userIterator(fileToSearch, false, "*", File::findFilesAndDirectories);
File nextFile = userIterator.getFile();
presetFolderConstructor(nextFile, presetFolder, fileIndex);
String name = nextFile.getFileName();
else if (nextFile.hasFileExtension(".uap"))
This code works correctly on WinXP through Win 10 and Snow Leopard through Sierra. High Sierra is the first to misbehave. Here’s an example of the seemingly random order:
issue confirmed here under 10.13
I didn’t see anywhere in the documentation for the class that it claims the order searched will be alphabetic. Did I miss something? https://www.juce.com/doc/classDirectoryIterator#details
It’s not supposed to return sorted items, no. It returns them in the same order as the underlying file-system returns them. You’ll have to sort your returned items yourself.
ah, that’s right! I guess we were just expecting that because it has always been the default behaviour.
Anyway, that should do :
DirectoryIterator iter (directory, false, "*", File::findFilesAndDirectories);
for (auto& f : files)
Nice! I was trying to roll a solution over here but this is much cleaner. Many thanks.
I did look into solving it at a lower level near the “NSDirectoryEnumerator,” however I wasn’t finding an easy way to make that happen. Everything I found suggested a manual sort at that level which would be cool but then it would be hard to pass up the chain without rewriting a bunch of internal JUCE since all of those functions are expecting an enumerator instead of a sorted array. For example: ios - Sorting of array returned by a NSFileManager's subpathsAtPath: method - Stack Overflow
Yes, the DirectoryIterator definitely gives no guarantee about the order - I’m amazed that you were ever lucky enough to see them in alphabetical order at all!
A slightly better sort might be like the one we use inside Projucer:
static int compareElements (const File& f1, const File& f2)
return f1.getFileName().compareNatural (f2.getFileName());
getFolder().findChildFiles (files, File::findFiles, false);
The compareNatural method is smarter than a simple string comparison, and does a better job of sorting numeric prefixes and other things
and juce already has a file sorter !
getFolder().findChildFiles (files, File::findFilesAndDirectories, false);
bool putFoldersFirst = false;
File::NaturalFileComparator sorter (putFoldersFirst);
Ah, thanks, I forgot about that one!
@jules, imho it’s a really common operation to get a files list in natural order.
I already see I need it in different projects, and the projucer or KnownPluginList could also make use of it I guess.
adding an extra optional
sortNatural parameter (perhaps even
true by default) to
File::findChildFiles() could save some typing.
I’m pretty sure many of us would use it (e.g. when building menus listing presets files).
What’s your opinion? do you think it’s to much specific or would you consider adding it?
patch.txt (1,5 Ko)
Not really keen on adding yet another parameter to that method, which already has too many!
And sorting is something that would lead to feature-creep, I can imagine that if we had that parameter, next thing would be “hey can you just add another option to ignore leading numbers?”, “can you add an option to make it ignore case?”, “can you add an option to put folders first?” etc etc
Much better to keep those operations and decisions away from the File class.