Directory creation failure on MacOS

Audio Plugins
1

Some of my users running MacOS are facing a problem I cannot reproduce.
When first running and registering the plugin I create a path in the ~/Music/Audio Music Apps/ directory using something like the following:

File file = File::getSpecialLocation(File::userMusicDirectory)
  .getChildFile("Audio Music Apps")
  .getChildFile(JucePlugin_Manufacturer)
  .getChildFile(JucePlugin_Name)
  .getChildFile("myfile");

file.create();
file.replaceWithText("some content");

I do not test for errors.

I then read that same file on subsequent run of the plugin.
This works for pretty much all users, but it seems to fail for a few of them, that consequently need to register each time they run the plugin :frowning:

It appears create() does fail for them, and although they already have the ~/Music/Audio Music Apps/ path, the JucePlugin_Manufacturer and JucePlugin_Name ones are not created.
To solve the problem they need to create the path themself, and then the plugin creates the file without issue.
I plan on showing a clear message asking to contact support when create() fails, but I don’t understand why it fails as that directory should not require specific rights from what I understand.

Any idea of what could be the cause here, and how to avoid the problem?

2

Two possible reasons:

There are faulty installers from some manufactures (i won’t mention any names ;-), which can create the "Audio Music Apps* folder with root rights only, so it can be only written as root, which of cause is a bug, because its inside a user directory.

Otherwise it can be, that for some reasons the “Audio Music Apps” folder is a broken link to another location (I guess that some users did this, to relocate the logic library) But this link will break after APFS conversion.

2 Likes
3

Workaround could be to use “Application Support” folder as fallback solution.

1 Like
4

Maybe it’s related to Catalina TCC permissions?
https://blog.fleetsmith.com/tcc-a-quick-primer/

Matt

1 Like
5

Good call, next time I will ask them to check rights.

Regarding broken link, yes one user had a link, and simply replacing it did solve the problem.

Application Support fallback could be a solution, but I fear having two directories to deal with can become a nightmare in the long run.

6

Never heard about this, thanks for the pointer!

Now that I look closely on the three reports I have, the one on 10.13 had a bad link and simply had to recreate a proper music apps folder, whereas the two on 10.15 had to create the full path.

7

I have a wrapper class, which first checks if the fallback settings folder exists and is accessible, otherwise it uses the Audio Music Apps folder. There is no danger, because once it exists it will always use it.

Otherwise it was a support nightmare, tell inexperienced users to fix their rights.

1 Like