• 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: Mike Abdullah <email@hidden>
  • Date: Thu, 23 Aug 2012 09:48:49 +0100

On 23 Aug 2012, at 03:14, Graham Cox wrote:

>
> On 23/08/2012, at 9:37 AM, Graham Cox <email@hidden> wrote:
>
>> Trying to work around this is proving impossible with the current sandbox implementation - there are too many opaque hacks in the system that mean you cannot trust the URLs you get from anywhere to actually point to the right place, and you also have to hard-code paths in your entitlements which are extremely fragile under both localisation and system updates. (For example, if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that location changes, or is named differently, my app stops working. Note the name of the iPhoto Library did subtly change between 10.7 and 10.8 - the space is a different unicode character now).
>
>
>
> Well, I spoke too soon, and have actually solved this problem. Whether it proves to be robust I can't say, but it wouldn't seem to be any worse than our un-sandboxed app in that respect.
>
>
> Turns out the problem I was having with this is because of the behaviour of [NSURL fileURLWithPath:isDirectory:].
>
> When I passed the path to the iPhoto database file (~/Pictures/iPhoto Library/Album.xml) the resulting URL was bizarrely altered to point to some non-existent path within my sandbox. In fact it looks like a bug because it ended up concatenating 'file://' somewhere in the middle of the path which makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly.

Your description here sounds unlikely. The URL APIs are extremely well-tested and robust; I would be surprised if you really have found a bug like this.

What is the path you were sending into +fileURLWith… ? Your description suggests it contains a ~ symbol, which NSURL is not going to resolve for you. If +URLWithString: is working instead, then most likely you never had a path to start with, but a string representation of a URL.

Where did this path even originate from, considering all the relevant APIs use URLs these days?

Of course I might be wrong and you’ve found a bug. If so I would like to be aware of it and file a radar on the subject.


_______________________________________________

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


  • Follow-Ups:
    • Re: Sandboxing die.die.die
      • From: Graham Cox <email@hidden>
References: 
 >Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Jens Alfke <email@hidden>)
 >Re: Sandboxing die.die.die (From: Kyle Sluder <email@hidden>)
 >Re: Sandboxing die.die.die (From: Alex Zavatone <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Sandboxing die.die.die
  • Next by Date: Re: text highlighting with CALayer and NSTextVew
  • Previous by thread: Re: Sandboxing die.die.die
  • Next by thread: Re: Sandboxing die.die.die
  • Index(es):
    • Date
    • Thread