Re: Sandboxing die.die.die
Re: Sandboxing die.die.die
- Subject: Re: Sandboxing die.die.die
- From: Graham Cox <email@hidden>
- Date: Wed, 22 Aug 2012 15:45:36 +1000
On 22/08/2012, at 2:46 PM, Laurent Daudelin <email@hidden> wrote:
> That's really bad news. I have a synchronization app on the App Store and I was hoping to update it with those security-scoped URLs but if it doesn't work for the content of folders, then I'm hosed.
OK, I think I see what needs to happen.
The documentation isn't crystal clear, because it seems to suggest that you would use -startAccessing and -stopAccessing whenever you need to access a resource using the URL, which is what I attempted to do. However, there are so many places in the system that open files using a URL that clearly do not do this (and hence fall foul of the wicked witch of the north, er, I mean sandboxd) that I started to wonder whether my interpretation was correct.
So I read the documentation literally. It says as soon as you resolve a bookmark, do the startAccessing thing. Then when you're finished (in my case my URL is owned by an object of mine, so I can do it in -dealloc) do the -stopAccessing thing. In other words leave it "open" all the time.
Sure enough, that does now appear to work, allowing access to the folder and all of the files and folders within it.
I'm still falling foul of sandboxd in a few other areas that seem a bit strange, like dragging and dropping files. It appears to ask the system for a sandboxing extension for the drag but fails internally, even though I do have permission thanks to the above. So this would appear to be an unrelated issue.
> the whole sandboxing enchilada seemed to be something that was quickly put together without much thought.
Understatement of the century :)
I bet if there were a cost/benefit analysis done on sandboxing, taking into account all of the time, effort and stress it is causing external developers, it would clearly be an outstandingly pointless exercise.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden