Feature Request: SpecialFolder.Container to return App Support folder of a sandboxed OSX app

We need a safe method to get a FolderItem pointing to the Application Support folder of a sandboxed app.

The existing method ‘SpecialFolder.ApplicationData’ will not always point to a folder inside of a sandbox container.

Now, if we have a folder with the same name in the container as well as in /Library/Application Support, then ‘SpecialFolder.ApplicationData’ will point to the FolderItem outside of the sandbox.

Example:

SpecialFolder.ApplicationData.Child(“MyApp Pro”) gets

/Users/JoeSixpack/Library/Application Support/MyApp Pro

instead of:

/Users/JoeSixpack/Library/Containers/com.firm.pro.myapp/Data/Library/Application Support/MyApp Pro

http://feedback.xojo.com/case/31856

Added as a favorite.

I’ve never seen this to be true. Are you sure this isn’t a debug issue? If your app is not sandboxed - which is common during debug - then the paths returned will of course not be inside the container.

Even if you’re setting up the sandbox for debug runs, I’ve found it can fail for no reason. That could silently exhibit the behavior you’re seeing. That’s why in my code, I detect the sandbox at app launch and warn me if the code sign failed. Just look for the APP_SANDBOX_CONTAINER_ID environmental variable.

i use appwrapper, which nicely shows any such errors.
otherwise, yes, i’m sure it is not a debug issue. it is as i descibed above.

Ok. Then I think you’re approaching this backwards. You’re suggesting a solution, rather than requesting that SpecialFolder.ApplicationData (or any of the SpecialFolder functions) be fixed.

I see no reason for SpecialFolder.Container, that’s something your application shouldn’t know directly. And for the record, I see no declare that would return such a path anyway.

Currently, SpecialFolder.ApplicationData.Child(“myFolder”) is returning myFolder from the container, but ONLY if there is no myFolder in the corresponding non-sandboxed library path. if there is such sibling, then xojo silently returns the non- sandboxed folder (called from a sandboxed app).

This is what I was reporting and yes, i would like to see a reliable solution to this, whether there is an api or not.

Something isn’t making sense here. What SpecialFolder.ApplicationData returns cannot be affected by what is called next. Are you saying that SpecialFolder.ApplicationData returns the correct path, but SpecialFolder.ApplicationData.Child(“myFolder”) returns the wrong one if there is an unmigrated directory? That doesn’t seem possible.

Do you have a migration plist in place that could be affecting OS behavior?

[quote=60700:@Thom McGrath]…
Do you have a migration plist in place that could be affecting OS behavior?[/quote]
Sorry,your post was not the answer, yet. I just mis-tapped on my iPad, and it seems it can not be un-done.

I will look into your plist suggestion tomorrow morning. It is 9:30 pm over here and about time to leave this darn thing.

[quote=60716:@Oliver Osswald]Sorry,your post was not the answer, yet. I just mis-tapped on my iPad, and it seems it can not be un-done.

I will look into your plist suggestion tomorrow morning. It is 9:30 pm over here and about time to leave this darn thing.[/quote]
Heh, no worries.

I “undid” the answer for you.

I added a project and a sandboxed and codesigned built app to the feedback case, with the steps to reproduce the issue. You may want to verify the plist file. As far as I can see, there is no migration issue.

http://feedback.xojo.com/case/31856

Your test is faulty. What happens if you don’t use .Launch, such as displaying the native path instead?

(I already know the answer to this)

Your project demonstrates a problem with the Launch method. There is nothing wrong with SpecialFolder.ApplicationData.

[quote=60743:@Thom McGrath]…
Your project demonstrates a problem with the Launch method. There is nothing wrong with SpecialFolder.ApplicationData.[/quote]

Yes, you are right, f.NativePath shows correctly the Path to the sandbox, but f.Launch then opens the folder outside of the sandbox.

I stumbled over this when I tried to launch an installer.pkg which I had downloaded to a download folder inside of the container. But there was an old installer from a non-sandboxed version outside of the sandbox which was launched instead.

So there is a problem if I can’t rely on f.Launch.

Right. My point remains. You’re suggesting a solution instead of identifying the problem and asking the problem to be fixed.

Normally, I’d tell you to use the CLI “open” command, but in a sandbox you can’t access the shell. I believe your only remaining hope is to file a bug report about the Launch method.

I have added this to the existing report with a suggestion to change it from feature request to bug report.

(But, anyway, I actually still would love to see something like : SpecialFolder.ContainerData…)

It couldn’t work. It’s a folder that doesn’t apply if you’re not sandboxed, and can’t use if you are.

Look up using NSTask

Can you be more specific?

Not really as I’ve never used it myself, but from what research I’ve done for App Wrapper customers, this appears to be one of the ways to launch an executable from a Sandboxed application.