My apps save a mutex file (in temp items) and a prefs file in user prefs folder. This has all worked fine for years, but today I have a single user on Big Sur (11.7.2) who is using one of my apps and my app is unable to delete or over-write the files that it has created in the above folders. You can access the folders via finder and delete them, but my app on this particular system can’t.
I’m not sure what error is occurring while my app is trying to delete the mutex or over-write the prefs as this build doesn’t show this. I sent my client a test app that does the same thing while displaying error messages, but this test app has no issue deleting files and over-writing files in the same folders. It’s as if macOS is not allowing my main app to delete files that it has created on this system. Is there anything I can reset in macOS? Or is there some permissions settings on a per app basis that can do this? My main app is signed with AppWrapper - for web deployment.
The next diagnostic step should be to see exactly what permissions/ACLs are being applied to the undeletable file. If the user is willing, get them to run “ls -le /path/to/thefile” and send you the output of the command. This will show the traditional UNIX ‘chmod’ permissions as well as the ACL (Access Control List) attributes for the file, any of which might be the culprit here.
@Eric_Williams Thanks. I didn’t know about ACLs and have now done a bit of research on the subject. I’ll run the “ls -le /path/to/thefile” command next time my client can share their desktop via Zoom. At least I’ll be able to compare the ACL settings of the files that can be written and the ones that can’t.
We have noticed some weird stuff going on since macOS Catalina was released. I’m convinced this is due to Apple introducing bugs in their old / deprecated File Manager APIs when accessing APFS formatted drives.
The problems we noticed were:
Applications could open files (for example, SQLite files) but not read the data correctly which meant the databases were reported as corrupted.
Applications couldn’t access files in the temp folder created by applications that had a different bundle identifier.
a) If our application crashed leaving the Xojo mutex files present and we then opened another version of our application it could not replace the mutex file.
b) Our auto update helper apps couldn’t access temporary files created by our main app due to the helper apps having a different bundle identifier.
We couldn’t open files we had previously written due to macOS adding extended attributes to files automatically (the same problem could occur if you added labels to a file via the Finder).
If I run the following code in Xojo 2019r1.1 and Xojo 2022r4.1 I see that the older version of Xojo has a different temp path:
Dim f As FolderItem
f = SpecialFolder.Temporary
If possible, I suggest you upgrade to a newer version of Xojo to see if the problems disappear.
We haven’t upgraded our project due to issues with newer versions of Xojo but have managed to partially solve the problems via the following:
a) Where possible, using our own temporary folder within the Application Support folder.
b) After writing files using the MBS plugins to clear the extended attributes.
Dim attributeList(-1) As String
Dim count, i As Int32
attributeList = ExtendedAttributesMBS.ListAttributes(pDestinationFolderItem)
count = UBound(attributeList)
For i = 0 To count
Call ExtendedAttributesMBS.RemoveAttribute(pDestinationFolderItem, attributeList(i), ExtendedAttributesMBS.kNoFollow)
@kevin_g Many thanks for the info. Yes I did notice that the temp folder for newer versions of Xojo has changed. The odd thing is I’m getting the same issue in the …/T/TemporaryItems folder as a user preferences/custom_folder folder. Also in the …/T/TemporaryItems folder the mutex file can’t be deleted by the app while three small temp WAV files that the app creates can be deleted.
Many thanks for the MBS plugin code. I might add this to my test app and send this to my client to try.
@Eric_Williams Looking at the client machine at the prefs file that my app can’t over-write, the file shows:
-rw-r–r–@ 1 USERNAME staff 7276 5 Jan 20:22 FILENAME.txt
This is the single line that ls -le filename returns, and the user name that is shown is the user that macOS is logged in as. This is the same as what is displayed on my system where my app works. I’ve found you need to add a ACL with chmod for ls -le to display any ACL permissions info on subsequent lines.
I’m also seeing the same permissions being displayed for the 4x files in the …/T/TemporaryItems folder. The first is created by the mutex, the other three WAV files are created by my app by writing a binary file. All 4x files have the same permissions. On app quit my app can delete the 3x WAV files but it can’t delete the mutex file.
Is there some other extra level of permissions I need to look at or a terminal command that I can use to see why the permissions seem to be different with these files?
@ChristopheDV AFAIK you don’t need to provide special entitlements while code signing to read and write files to these folders. I ran my app on a fresh version of Ventura and macOS also didn’t prompt the user (me) to allow the my app to read or write to these folders. I do however have AppWrapper setup to add entitlements for folders like Documents, Desktop…
I tried deleting clearing these attributes, which were removed but made no difference in terms of allowing my app to delete the file.
I’m getting my end user (client) who works at a large company to get their IT department to look into this. I’ve been told the IT department creates each mac system from an image which is then managed by JAMF, which installs the base apps, and imposes policies on top of the OS. Maybe their system has has worked fine for years with my apps is doing something odd with Big Sur.
Thanks for all the help. Will update when I know more in case this helps others.
Unfortunately this could mean that any of the rules that you would have on an unmanaged system may not apply on this user’s system. JAMF is used by IT where I work now and we run into oddities all the time.