I’ve had several customers report in the last few months that Lightwright isn’t saving their current settings or registration information, both of which are stored in this location.
Can anyone think of a reason why this location would be unavailable or not be writeable?
I’ve asked the afflicted users if the com.mckernon.lightwright6 folder gets created, but they’ve been slow to respond. For that matter, would there be any reason why an app wouldn’t be able to create that folder? Normally, Lightwright creates it upon launch or when saving settings or other data. Some users report they do have read/write privileges for com.mckernon.lightwright6 folder, so I’m baffled.
I cant offer a reason, but I can chip in and say I’ve seen this happen too.
When people email for support, I attach the error log for a ‘snoop’. Many of them are getting errors relating to being unable to save a prefs file for no apparent reason.
I second this, add some code to check the existence of this folder, it’s permissions (which you can get via Xojo API) and it’s locked status. One thing to bear in mind is that the permissions will return the user permissions, not the application permissions! I’ve encountered scenarios with a Sandboxed application where the permissions report this file is 777 (or whatever) but I can’t open it, permission denied.
I would go one further, add a menu option to the Help Menu called “e-mail support” and use the ShowURL function to automate an e-mail addresses to you with relative information (log if must be), this is a huge time saver with support.
What version of the macOS?
Lastly what code are you using to get the Application Support folder?
I know that what you’re doing is/was allowed and like I say technically it shouldn’t make any difference.
If your application was Sandboxed (which I know you say it isn’t) then your problem is that the application container has become corrupted, the only reason I know for creating a corrupted container is Security-Scoped Bodgemarks not being released within the 90 second window.
Failing that, the only other conclusion I have is that the Apple updater is bolloxing up the permissions when it updates the OS (which is quite possible) or when the drive is converted to APFS.
It doesn’t. The only warnings in the documentation are as follows.
What I’ve found is that if you don’t release them within 90 seconds, it can lead to a container corruption, whereby your application becomes severally crippled in functionality until the container is deleted.
You also have be warry of Apple’s lazy loading functions; for instance I ran into a problem with CGImages on a slow machine, whereby I was requesting access to a file, loading the full resolution image, releasing access to that file and then drawing the image. What I didn’t know at the time, is that the image data isn’t loaded until it’s needed. The solution is to force CoreGraphics to cache the image when it loads it (there’s a key you can pass to the CGImageSource).
[quote=416531:@Michael Diehr]Some ideas for “weird stuff on macOS”:
they are running on case-sensitive HFS system (aka ‘Satan’s own FS’)
they are running as a non-Admin macOS user
they have more than one user logged in at once (I think Xojo has some weird bug related to this)[/quote]
= Since my code is all using the same case for all of the filenames, then case sensitivity shouldn’t be an issue, right? Or is there something else about case-sensitive HFS that makes it problematic?
= Very few of my Mac users are running antivirus software, and none of the ones who have run into this problem say they are.
= The info being saved is often preferences and other user-specific info, why would they need Admin status to access the data in their Application Support folder?
= Having more than one user logged in at once sounds like it might be something to ask the users about, but I’ve always assumed that since Application Support is in each user’s Library folder, that they would be essentially walled off from each other. Is this not true?
And FWIW, When my app reports to the user that it can’t access the Application Support Folder, it offers users a one-click way to send the relevant debug info to me, including the approximate line that the code failed on. I’ve seen nothing suspicious, just that the folder’s contents can’t be accessed.
So the question remains, how/why would files in this location not be readable or writeable? This is a single-user app, and only one process at a time reads or writes to those locations.