Sandboxed Mac app exhausting security scoped URL resources

Question

I am developing a Mac application that prompts the user for files using the NSOpenPanel. The application is sandboxed (testing on OSX 10.9.4). I noticed that if I open a large a

Answer 1

After searching high and low and asking in various places, I am going to close this question and conclude there is no answer or solution to this. I am posting the known information on this for future reference.

All the solutions suggested are just workarounds that may minimize the problem and try to guide the user toward not trying to open too many files. But there nothing that can be done to actually solve this.

Here are the known facts about this issue:

• No matter what you do, the user can attempt to open too many files in the NSOpenPanel dialog and exhaust the security scoped URL resources
• Once these resources are exhausted, it is not possible to open any more files for reading/writing. The application needs to be closed and reopened
• Even if the user doesn't attempt to open too many files at once, the application may still exhaust these resources if it runs long enough and the user opens enough files over time since startAccessingSecurityScopedResource is called automatically for files opened with NSOpenPanel (or the drag/drop mechanism) and nothing ever closes these resources
• Calling stopAccessingSecurityScopedResource on all URL retrieved by the open panel will free these resources but this practice is discouraged by Apple, saying it might not be compatible with future solutions
• When you receive the list of URLs from NSOpenPanel (or drag/drop), there is no way to tell if all URLs were successfully accessed or if there are URLs that are over the limit and therefore invalid.
• Apple is aware of this and may fix it in the future. It is still not fixed in 10.10 and of course, that will not help current applications running on current/previous OSX version.

It seems Apple has really dropped the ball on this one, the Sandbox implementation seems very sloppy and short sighted.

Answer 2

The behavior you experience is because the security scoped resources are limited:

NSURL - (BOOL)startAccessingSecurityScopedResource tells

If sufficient kernel resources are leaked, your app loses its ability to add file-system locations to its sandbox...

The current limit is roughly what you experienced. See: What are the current kernel resource limits on security-scoped bookmarks?

To prevent it:

• only start accessing those SSBs you need at a given time and subsequently stop accessing them
• start access not files but enclosing folders: ask the user not to choose files but a full folder. This will grant you access to the whole tree beneath that directory
• on draggingEntered: show a NSOpenPanel with the enclosing directory(ies) to grant access