File.move to user library on a Mac - help!
-
Congrats on launching the new installer system
-
@griffinboy thank you!
-
@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...
-
@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.
-
@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
-
@d-healey thank you, but this doesn't seem to work when I test it. Shoud it be (false, false) or (fase, true)?
-
@tomekslesicki Either, depends on if you want it to apply to all sub-folders.
-
@d-healey that's what I thought. The 2nd true will mean that subfolders are supposed to be affected, too, right?
-
@tomekslesicki Yes
-
@d-healey thank you!
