Can't read/write to macOS Application Support folder?

  1. last week

    John M

    Nov 30 Pre-Release Testers, Xojo Pro New York / New Jersey

    My Lightwright app is a non-sandboxed desktop app, built with Xojo 2016R3. It stores its settings, registration info and other data on macOS in

    User:Library:Application Support:com.mckernon.lightwright6

    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.

    Thanks!

  2. Jeff T

    Nov 30 Midlands of England, Europe

    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.

  3. Beatrix W

    Dec 1 Pre-Release Testers Europe (Germany)

    Don't ask your users such complicated stuff. Add the permissions check to your logs and let the users send back the log.

    Never seen this before.

  4. Sam R

    Dec 1 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Beatrix W Don't ask your users such complicated stuff. Add the permissions check to your logs and let the users send back the log.

    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?

  5. scott b

    Dec 2 Pre-Release Testers, Xojo Pro local coffee shop

    @Sam R Lastly what code are you using to get the Application Support folder?

    I tend to use SpecialFolder.ApplicationData.child( “company name” ) and place a folder in there for the application.

  6. Sam R

    Dec 2 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @scott b I tend to use SpecialFolder.ApplicationData.child( “company name” ) and place a folder in there for the application.

    The only thing I can see that *might* be a problem is that typically, you'd just use your application bundle identifier.

    SpecialFolder.ApplicationData.child( “com.ohanaware.appWrapper3” )

    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.

  7. Michael D

    Dec 2 Pre-Release Testers, Xojo Pro

    Some ideas for "weird stuff on macOS":

    • they are running on case-sensitive HFS system (aka 'Satan's own FS')
    • antivirus software
    • 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)
  8. Sam R

    Dec 2 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Michael D they are running on case-sensitive HFS system (aka 'Satan's own FS')

    I've actually been contemplating doing this on my own machine, so then at least it reduces the chances of me screwing up... I said reduces, not prevents :)

  9. Thom M

    Dec 2 Pre-Release Testers Greater Hartford Area, CT

    @Sam R the only reason I know for creating a corrupted container is Security-Scoped Bodgemarks not being released within the 90 second window.

    Uh... say what? Where in the docs does it say they need to be released in 90 seconds?

  10. Sam R

    Dec 3 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Thom McGrath Uh... say what? Where in the docs does it say they need to be released in 90 seconds?

    It doesn't. The only warnings in the documentation are as follows.

    Warning: If you fail to relinquish your access to file-system resources when you no longer need them, your app leaks kernel resources. If sufficient kernel resources are leaked, your app loses its ability to add file-system locations to its sandbox, such as via Powerbox or security-scoped bookmarks, until relaunched.

    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).

  11. 7 days ago

    John M

    Dec 3 Pre-Release Testers, Xojo Pro New York / New Jersey

    @Michael D Some ideas for "weird stuff on macOS":

    • they are running on case-sensitive HFS system (aka 'Satan's own FS')
    • antivirus software
    • 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)

    = 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.

or Sign Up to reply!