File.move to user library on a Mac - help!

[tomekslesicki]

I'm getting some serious inconsistency with the File.move command when moving files to the user library folder on macOS. Whenever I test it - whether in HISE or in a built standalone app - the command works properly. I'm getting some reports from users about the files not being copied over. My script looks like this:

// Check if file exists and remove it if it does
if (componentFileMac.isFile() || componentFileMac.isDirectory())
{
    componentFileMac.deleteFileOrDirectory();
}

workingFolder.getChildFile(pluginname + ".component").move(componentFileMac);

All vars used are defined properly and again, it works on macOS 12.4 and above. I guess the issues is with some older macOS version, but I'm yet to confirm that. Anyway - is there something about using the .move command to get the files to the user library I should know about? Clearly, it's a permissions issue. Is the .copy method safer? What's the smart way about it?

As a walkaround I could start a .pkg from the main script just to get the files in place, but it's a custom installer and I think it would be great to keep the experience consistent without running yet another app from the main app.

[d.healey]

@tomekslesicki I haven't ran into any issues with it but the JUCE documentation says that the move function can fail so it can be better to copy the file and delete the original if the copy is successful.

JUCE: File Class Reference

(docs.juce.com)

[ustk]

@tomekslesicki @d-healey Wouldn't it be safer to use a background task with a shell command anyway? Seems asking for troubles to do this from Hise/exported binary... @aaronventure seems to master this bit...

[aaronventure]

@ustk BackgroundTask is a great fallback option when the JUCE/HISE stuff seems to be inadequate for the job, but David's making a lot of sense in his post, too.

[tomekslesicki]

@aaronventure @ustk @d-healey thank you!

@ustk could you please give me an example of the background task running a shell script so I can test this?

[d.healey]

@ustk said in File.move to user library on a Mac - help!:

Wouldn't it be safer to use a background task

Well I haven't ran into any issues with it, however in a recent update in Rhapsody I've put the move file stuff into a background task (no shell script), but not because it was failing, but because it was holding up my GUI.

[aaronventure]

@tomekslesicki https://docs.hise.dev/scripting/scripting-api/backgroundtask/index.html#runprocess

You can drop an entire script as a string as an argument into runProcess. Just pretend you're calling the script from a terminal. ChatGPT can help you here a lot.

Keep in mind that you'll need different variations of the runProcess function for Windows and macOS, as you'll use PowerShell on Windows and probably bash on macOS.

[tomekslesicki]

@aaronventure I already have a working shell script from the pkg installer I had earlier, so I could definitely reuse that. I'm totally new to background tasks, though. Could you please help me out to understand what I should pass into the docs example? Thank you!

[aaronventure]

@tomekslesicki BackgroundTask.runProcess(var command, var args, var logFunction)

the command is the string of a command, like "bash", and args are any args that would follow a terminal command.

Inyour case

const scriptStr = "myScript";

BackgroundTask.runProcess("bash", ["-c", scriptStr], function(thread, isFinished, data)
{
    // Function body
});

The function will execute every time the terminal would output something, as well as once more on isFinished == 1. Data is the the terminal output string.

Be careful regarding escaping for new lines, paths etc. It'll take some trial and error.

Try the docs example in an empty project and try with very simple stuff like making curl calls to a test API endpoint, or just calling help commands for an app, etc.

[tomekslesicki]

@aaronventure Perfect, thanks so much!

[griffinboy]

@tomekslesicki

Congrats on launching the new installer system

[tomekslesicki]

@griffinboy thank you!

[Christoph Hart]

@tomekslesicki kind of unrelated, but I realized an issue with file permissions on macOS that I wasn't aware of and this also might be the reason for why the move operation fails with your users:

usually you would expect that the user has read & write access to its user app data directory. However if you create the app data folder during your installation routine while having elevated admin privileges, it will inherit the user rights and treat it as a folder outside the user domain. This will lead to all subsequent read & write operations to that folder to fail which is super catastrophic as it will not store the link file, settings or license files.

We ran into that issue a few days ago when beta testing an update and it turns out that our installer created these folders after copying the plugin files to the global plugin folder (which requires admin privileges, hence the entire script ran with elevated privileges).

I could reproduce this very easily with a non-admin account, but other beta testers even experienced that issue with an admin account, which sounds super fishy...

[tomekslesicki]

@Christoph-Hart from what I see, File.createDirectory() creates read-only folders, even if the parent folder is set to read & write. At least on Windows.

[d.healey]

@tomekslesicki said in File.move to user library on a Mac - help!:

File.createDirectory() creates read-only folders

Not here. But you could always call this after

[tomekslesicki]

@d-healey thank you, but this doesn't seem to work when I test it. Shoud it be (false, false) or (fase, true)?

[d.healey]

@tomekslesicki Either, depends on if you want it to apply to all sub-folders.

[tomekslesicki]

@d-healey that's what I thought. The 2nd true will mean that subfolders are supposed to be affected, too, right?

[d.healey]

@tomekslesicki Yes

[tomekslesicki]

@d-healey thank you!