Plug-ins Duplication in Scanner

Hello wonderful people of juce !!!

It has been reported to us that in our DAW, some VST plug-ins are duplicated. I was able to reach the bottom of this and understood that the method which is causing the issue is this

std::unique_ptr KnownPluginList::getTypeForFile (const String& fileOrIdentifier) const

and specifically the line

if (desc.fileOrIdentifier == fileOrIdentifier)

In case of a file, this is not accurate as in Windows the file paths are not case sensitive. I was ending up having the same plug-in in my xml cache file because the user changed the path from c:\Something to c:\something.

This is the fix I provided but you may decide on a better approach

if (desc.fileOrIdentifier == fileOrIdentifier || (juce::File::createFileWithoutCheckingPath(desc.fileOrIdentifier) == juce::File::createFileWithoutCheckingPath(fileOrIdentifier)))
return std::make_unique (desc);

Sounds to me that the uid would be a much better fit? or both:

if (desc.fileOrIdentifier == fileOrIdentifier || desc.uid == uid)

I wouldn’t really agree on that. The uid will be the same between 2 different versions for example of the same plug-in that exist in different directories. In which case, It wouldn’t be so wrong to get these plug-ins duplicates.

Fair point, I didn’t think of different versions.

Looking at it again, since there seem to be cases where a duplicate is expected to be present in the list and other kinds of duplicates aren’t, I think this kind of filtering is best done in the user code and not in the library code. That way the user can decide if they want to offer selecting different versions for their users or which version they would pick.

Just my 2 cents.

Agreed with @daniel that it is not the framework job to deal with this case.

And actually the fix you offer @gdrakos79 (if I understand it correctly) could be considered as broken for some user. Let’s take an example: I have a plugin “Effect” from “CompanyA” which I want to have in 2 versions for some reason, let’s say v1.0 and v2.0. In my VST/CompanyA folder, I decide to have both DLLs as “effect.dll” and “Effect.dll” (some systems allow that). With your fix, only one of them would show up in your DAW.

What you could do in my opinion, instead of silently doing the Logic you suggest, is popup a warning and let the user decide on what to do.

The way I see it (and I might be wrong) is this:

The person who initially implemented the function and placed
if (desc.fileOrIdentifier == fileOrIdentifier)
intended to return true when the files are the same (or the identifiers are the same)

The juce::File == operator in juce correctly takes case sensitivity into account

static int compareFilenames (const String& name1, const String& name2) noexcept
{
#if NAMES_ARE_CASE_SENSITIVE
return name1.compare (name2);
#else
return name1.compareIgnoreCase (name2);
#endif
}

This method does not. So with my fix, what I tried to do is to be consistent with the initial logic of the developer and return true when the files are the same no matter the O/S. Because simply this method will behave differently in Linux and Windows.

That said, if all agree that it is correct as it is then I pass and I can workaround my issue one way or another.

Thank you for taking the time

I have no say in the decision and I can live with either way. But I notice your report exposes a deeper problem:

The NAMES_ARE_CASE_SENSITIVE is set at compile time depending on OS. But any OS can work on file systems that are either case sensitive, case preserving or case insensitive. So this should really be checked at runtime depending on the FS type. Sorry if that leads a bit off-topic, but it is the reason for this thread.

2 Likes