I get this complaint sometimes from my Mac clients. I can’t replicate it, and I know it’s not everyone.
I have a file that when I build, gets written into the Resource folder in the App bundle. It’s fairly critical for certain operations, it’s just got a lot of binary preset data and it only needs to be read.
On my build computer, it’s permissions are R+W for all users. When the app is built, those permissions stay that way. They go on a DMG, the customer gets it, and to install moves the app from the DMG and into the Applications folder. Normal.
I have a error dialog that shows when the sole function that reads this file can’t read it, telling the user to check his/her permissions. I just had a client do that, and the permissions on his system R+W from him but Read Only for the others. Still, though, I only read the file, never write it. I open it only with read rights.
My question is: how could this possibly happen where a file in my bundle can’t be read? I know anything is possible, but what are the most likely culprits. How can I help my client?
App Wrapper resets the permissions when you wrap your application, so there shouldn’t be a permissions problems.
Double check and make sure that when you open the file it is only read only and not read/write. You mention it is a binary file, but please tell me it is NOT a SQLite database. Xojo have point blank refused to add support for read-only databases, which prevents you from using Xojo’s SQLite databases in many situations.
Lastly there is a security situation introduced with Catalina that can prevent apps from opening files unless the user explicitly specifies them, this shouldn’t be happening with files in the Resources folder, however as this system is a black box, it may be a cause.
It is worth noting also that there is OS API for obtaining files in the resources folder, it may be possible that under certain circumstances the OS is passing some security values when using this API and NOT when using the Xojo folderitem API.
One potential solution is to copy the file to the Application Support folder, where your application has read & write access. You’ll need to create a solution for ensuring that file is up to date (do NOT rely on the file dates via the Xojo framework as there are bugs with Xojo’s dat/time conversion). Either use an alternative system or use OS API for file dates.
Can you use f.CopyFile (not f.MoveFile) rather than a Binary Read? Or store a Zipped version of your file instead.
I used to have a problem with Windows where the f.CopyFile would result in a file with the wrong permissions, but a binary read/write to the same location worked properly.
I have now experienced that too. In my program I had a build step that copies a folder with sound files into the program package and I accessed them using folderitem. This procedure comes from a time when the number of objects that were dragged into the project was still limited.
Access using folderitem now resulted to be asked for hard disk access permission. As a solution, I have now dragged these files into the project window and access them directly now.
Thanks for everyone’s responses; sorry, it wasn’t a permission issue, but a code snippet in my C++ dylib that is supposed to get the application path based on the bundle identifier. Looks like Sonoma doesn’t like some of the calls. Cheez, Apple, it’s OKAY to have functions around for 5+ years without deprecating them or having them fail.