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

[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!