PluginDirectoryScanner scanNextFile issues with known and up-to-date plugins



PluginDirectoryScanner’s scanNextFile() returns true for each previously known (and up-to-date) plugin … that is, cases where list.isListingUpToDate(file, format)==true.

However, in such cases the block where nameOfPluginBeingScanned gets assigned and where dontRescanIfAlreadyInList gets evaluated is never entered.

As a result, after the call, nameOfPluginBeingScanned will be empty or the name of the last plugin the scanning of which entered that block. Further, setting dontRescanIfAlreadyInList to false has no effect if the plugin is already included in list and is up-to-date.

Or that is what my testing has found, fwiw.



Isn’t that the expected behaviour? If dontRescanIfAlreadyInList is false, then the plugin will be scanned regardless of if it is up to date or not. It’s also expected that nameOfPluginBeingScanned will not be set to the plugin name if the plugin isn’t being scanned because dontRescanIfAlreadyInList is true and the plugin is up to date.



Thanks for the response.

If dontRescanIfAlreadyInList is false, then the plugin will be scanned regardless of if it is up to date or not.

This is not what I see. For me, dontRescanIfAlreadyInList=false does not cause on-the-list/up-to-date plugins to be rescanned (which is explainable to me because the block of code where that bool is evaluated is never entered for on-the-list/up-to-date plugins):

if (file.isNotEmpty() && ! list.isListingUpToDate (file, format))
    nameOfPluginBeingScanned = format.getNameOfPluginFromIdentifier (file);

    OwnedArray <PluginDescription> typesFound;

    // Add this plugin to the end of the dead-man's pedal list in case it crashes...
    StringArray crashedPlugins (readDeadMansPedalFile (deadMansPedalFile));
    crashedPlugins.removeString (file);
    crashedPlugins.add (file);
    setDeadMansPedalFile (crashedPlugins);

    list.scanAndAddFile (file, dontRescanIfAlreadyInList, typesFound, format);

    // Managed to load without crashing, so remove it from the dead-man's-pedal..
    crashedPlugins.removeString (file);
    setDeadMansPedalFile (crashedPlugins);

    if (typesFound.size() == 0 && ! list.getBlacklistedFiles().contains (file))
        failedFiles.add (file);

… so if list.isListingUpToDate(file,format) is true, then dontRescanIfAlreadyInList isn’t evaluated because list.scanAndAddFile is never called, nor is nameOfPluginBeingScanned set.

I guess it is debatable the expected behavior of setting nameOfPluginBeingScanned. I may not be a representative enough user, but I’d prefer that value to be set for each true return that scanNextFile() generates (i.e. here’s the plugin that contributed to the call’s return). To me, it is already not expected behavior for a function called scanNextFile() to separately return for each file it evaluates for scanning, whether or not it actually scans it. That is, scanNextFile()==true means either a plugin was scanned and I can trust/use the nameOfPluginBeingScanned value, or it means a plugin was skipped for being already known and up-to-date and I can’t use/trust the nameOfPluginBeingScanned value … but I have to do extra maintenance of previous scanNextFile() returns to decide between those two cases. Like I said, if other users are happy with it as-is, then certainly leave it as-is.



Which version of JUCE are you using? This is how scanNextFile() looks currently, and you can see that dontRescanIfAlreadyInList is evaluated before scanning.


I have an older version, but I had thought I checked against the latest download, too. Sorry about that … yes, I see it is resolved in the latest version.