[bug] Encrypted expansions magically turning into file based
-
-
@d-healey Ah OK, so inside
Expansion.unloadExpansion()
would be the most reasonable place to set this flag, right? -
@Christoph-Hart Sounds reasonable to me
-
Is there ever a reason to create the expansion xml automatically in the destructor?
-
Ok I added the flag and it works! But I realised there is another scenario we haven't considered.
What about when the user has HISE running and then goes into their OS file browser and deletes the expansion files. The xml will still be recreated by the destructor.
-
@Christoph-Hart Any suggestions?
-
I think it should be safe to assume that if the directory doesn't exist, it shouldn't write that data to the file so this would handle this case too.
-
@Christoph-Hart The problem is that if the directory does exist but the content is removed (as in my video) the files are recreated.
We need to make sure the files are never recreated by the compiled project I think, unless you know a reason why they should be.
I guess it would also be good to also not create the files if the directory exists but is empty, that would prevent it happening when running in HISE.
-
I think I've found a suitable solution, can you see any issues with it?
~Expansion() { if (root.isDirectory() && root.getNumberOfChildFiles(File::TypesOfFileToFind::findFiles, "expansion_info.xml") > 0) saveExpansionInfoFile(); }
-
@Christoph-Hart This solution good for a pull request?
-
Instead of
root.getNumberOfChildFiles(File::TypesOfFileToFind::findFiles, "expansion_info.xml") > 0
you can just write
root.getChildFile("expansion_info.xml").existsAsFile()
this will prevent iterating over the entire directory with the same outcome.
-
@Christoph-Hart Ah nice, ok. I'll make that change and create a pull request. Thanks for your help!