• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sandboxing die.die.die
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing die.die.die


  • Subject: Re: Sandboxing die.die.die
  • From: Laurent Daudelin <email@hidden>
  • Date: Tue, 21 Aug 2012 23:34:37 -0700

On Aug 21, 2012, at 22:45, Graham Cox <email@hidden> wrote:

>
> 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

Thanks, Graham, I can now starting to breath normally! I might have a few questions when I'm ready to take my app to the next step, but that's not happening anytime soon.

Thanks for the follow-up!

-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 				http://www.nemesys-soft.com/
Logiciels Nemesys Software					email@hidden


_______________________________________________

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

References: 
 >Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Laurent Daudelin <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Sandboxing die.die.die
  • Next by Date: Crash with UITableView reloadRowsAtIndexPaths:withRowAnimation:
  • Previous by thread: Re: Sandboxing die.die.die
  • Next by thread: Re: Sandboxing die.die.die
  • Index(es):
    • Date
    • Thread