At last the almost holy grail of Sandboxing

If you’ve seen my previous messages then you’ll understand the ordeal I’ve been through in trying to do a better job of handling file access when my app is Sandboxed. I’ve been here, there, around a bit and discovered a couple of hacks that seem to work.

The latest one, seems the most promising however and hopefully won’t be too hard for RS to help us all out. I’ve created a feedback case requesting that two events be added to the application class. Within these events, if you store and retrieve files using Lion’s resume system, access is held.


Is this affected by this?

I would imagine so as it’s part of the OS functionality for WindowRestoration.

So, people who opted to disable it, could break your workaround and get you unexpected problems. Take care. :wink:

It depends.

Are you doing your own restore/resume functionality ignoring this setting? If that’s the case, then it may not work correctly.

Unless you use NSDocumentController to make sure that your files are in the Recent Items list (this also automagically holds references for you). However the user can set the limit on the amount of files that are in the Recent Files list, which is why I was exploring alternative solutions.

Failing that, you can either store all your data in the application container or resort to Security Scoped Bodgemarks (which can fail on you at any time).

You meant “If that’s the case, then it may work correctly”?

I mean, you know it can be on/off, you don’t care, you had taken the necessary steps for any case.

Great job, Sam. It has been interesting watching the evolution of your research. :wink:

I’m getting a little confused here and so would like to just clarify how this currently works.

If you have an application that maintains windows through application restarts, you should either.
#1 Pay attention to what the user wants by checking to see if they want persistence, and if they do then using the Lion Resume functions. If they have this option disabled, then your application should revert to a non persistent version (i.e. closing all docs on quit) and making the user re-open them when they re-open the application.
#2 Or if you ignore the setting, you should store all your data in a location that your application can read and write to, i.e. your application container.

You can utilize the OS provided Recent Items list, but as the user can change the amount of files in the list you shouldn’t rely on this.

It’s worth noting that by default an Obj-C NSDocument based application adhere’s to #1 automatically, you as the developer don’t have to do anything, when the Persistence is disabled, the application behaves like a traditional app, when it’s enabled it automatically provides persistence.

I hope that this makes sense. I have a little demo app, which also works using #1.