Can't Create a Folder in SpecialFolder.ApplicationData

When my app (Lightwright) launches, one of the first things it does is try to create a folder within SpecialFolder.ApplicationData to do work in, store settings, etc. This has worked great for years on both Mac and Windows, but one of my users (a university) just reported that on macOS Big Sur Lightwright cannot create the folder. It only works if user has admin privileges, it fails for all other users. In this case, the app is running on a bunch of Macs in their computer lab.

Here’s the relevant code:

gLWAppDataFolder=SpecialFolder.ApplicationData.Child(kLWBundleIDStr) 'Note: kLWBundleIDStr is “com.mckernon.lightwright6”

If gLWAppDataFolder=Nil Then 'Something screwy is going on

Quit
Return

End If

If Not gLWAppDataFolder.Exists Then 'Try to create it

Try

 gLWAppDataFolder.CreateAsFolder

Catch

gLWAppDataFolder=Nil

End Try

If gLWAppDataFolder=Nil Or Not gLWAppDataFolder.exists Then

MessageBox(kSorryStr+" Lightwright could not create a Temporary folder")
Quit
Return

End If

The user is getting the “could not create a Temporary folder” message. I’ve never had a user report this before, and I have other users who are happily running Lightwright on Big Sur.

Can anyone explain why this would be happening? How can I get it working? Is there some macOS magic I need to add for BS?

Thank you!

  • John

Hi John,
Can you catch the error to get something more explicit in error.Message and ErrorNumber?

Hi John,

I could be wrong (most likely), but I though there are some subtle changes under the hood for FolderItems (on macOS) between API 1.0 and 2.0.

So maybe try CreateFolder instead of CreateAsFolder?

I hope that helps.

Running in the IDE, last Xojo, last Big Sur, when my project want to read (anywhere), Big Sur ask for permission.

Are-you sure your customer do gave the permission ?

1 Like

First thing is to check and make sure that the kLWBundleIDStr is exactly the bundle identifier for the application.

Secondly, I’d capture the path if possible, I recently discovered that Notarization cannot occur when the user folder is on a volume with a space in the drive name!

Thirdly, Capture the error code. IOExceptions rarly have a message, but nearly always have an error code.

Fourthly, capture the application version and system version in the error dialog. Here’s an example of how I would handle that function.

Dim errorMessage as string
gLWAppDataFolder = SpecialFolder.ApplicationData.Child( app.infoBundleIdentifier ) 'Note: kLWBundleIDStr is “com.mckernon.lightwright6”

If gLWAppDataFolder = Nil Then 'Something screwy is going on
  ErrorMessage = "Unable to access"
  
elseif not gLWAppDataFolder.Exists Then 'Try to create it
  Try
    gLWAppDataFolder.CreateAsFolder
    
  Catch err as IOException
    ErrorMessage = "Failed to create, code: " + str( err.errorNumber ) + " path: " + gLWAppDataFolder.nativePath
    
  End Try
end if

if errorMessage <> "" then
  MessageBox kSorryStr + " ""Application Support"" folder issue occurred """ + errorMessage + """." + _
  endOfLine + endOfLine + "Version: " + app.infoVersionString + endOfLine + _
  "macOS Version: " + app.infoOSVersion
  
  Quit
  Return
end if

The more information you can capture the better, but shoesize doesn’t help!

1 Like

The last time I looked, all Apple computers Hard Disk (and SSD) names were “Macintosh HD”: a space exists in the Volume name !

But the xternal SSD I get recently was named Samsung_T5, and I had hard work to be abe to install a boot OS onto it (it have a boot Partition called Windows).

A couple of months ago I had half a dozen reports about my app not starting correctly. Turned out that the app couldn’t write to Application Support. The users used the uninstaller, reinstalled and everything was okay. I got the reports within a day or two. And then the problem never showed up again. macOS…

Seems like if macOS learned to allow the application to do that after some attempts.

Yes, kLWBundleIDStr is the same as the app’s bundleID.

I suspect the problem is they’re using jamf to handle their installs, and something in jamf may not be configured correctly.

I’ll also send them a beta version with more error checking, we’ll see what the exact error is.

Thanks!

And unfortunately, whenever I try to add Sam’s code to the app, Xojo crashes when autofilling on App.i

Feedback #65181

Try with an older version. I think that the bug already has been fixed.

1 Like

Because when the User folder is on the Boot Drive the Volume Name is irrelevant.

/Users/rowlands/Library/Caches

However when it is on a different volume it becomes

/Volumes/External Disk/Users/rowlands/Library/Caches

Apple’s submission tool accesses the Users folder, and chokes if the user folder path contains a space in it.

Odd, but we’re getting used to Odd issues in iOS macOS. I’ve only ever seen the TemporaryItems folder inaccessible and have experienced it myself. Rebooting the Mac seemed to fix that one.

Nice.

I apologize, I haven’t tested that code, it was only my interpretation of how I think it could be done, I am sorry for causing you grief.

And today I get this report from a user where the user doesn’t have access to the documents folder:

2021-07-04 14:27:58 An error happened:
2021-07-04 14:27:58 Class/Method: DefaultExportLocation.GetExportFolderNumbered
2021-07-04 14:27:58 Time: Sunday, July 4, 2021 2:27:58 PM Central Daylight Time 3923617
2021-07-04 14:27:58 Type of Error: IOException
2021-07-04 14:27:58 Error Number: 1
2021-07-04 14:27:58 Error Message: You don’t have permission to save the file “Mail Archiver X” in the folder “Documents”.

image

Sadly that’s actually “Normal”.

In App Wrapper, go to the Capabilities Page, under the files and folders heading, enter a “Usage message” next to the “Documents” folder. Then the user should be asked, next time they want to save files to the Documents folder.

What is unclear to me is exactly which “Usage Messages”, actually need to be filled. Sometimes you don’t need to fill it it, and sometimes you do, AppleScript YOU must fill in. I’d refer to Apple’s documentation, but it doesn’t always state and there’s no guarantee it’s up to date.

You are probably correct. Normally, my app needs full disk access anyways so I don’t often get those stupid messages - at least for my own app.

1 Like

I am not 100% sure either, guessing is more like it.

Again, I’ll complain that it would be nice if we had documentation that made this clear and that we could trust, but that would eat into Apple’s profitability, so we flounder around like fish out of water instead.

Let me know if it does help.

Also talk to @Thomas_Tempelmann as he’s implemented a brilliant UI for aiding customers to enable Full Disk Access from your Mac application (Albeit you may need to use Twitter or e-mail to get ahold of him).

You mean like the well known “Macintosh HD”? Even if they are no longer named that way (I don’t really know), they forgot their root…