• 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: Fri, 24 Aug 2012 13:35:40 +0100

On 24 Aug 2012, at 00:33, Graham Cox wrote:

>
> On 24/08/2012, at 3:11 AM, Greg Parker <email@hidden> wrote:
>
>> On Aug 22, 2012, at 7:14 PM, Graham Cox <email@hidden> wrote:
>>> 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.
>>
>> From the +fileURLWithPath:isDirectory: documentation:
>> "If path begins with a tilde, it must first be expanded with stringByExpandingTildeInPath."
>>
>> Note also that paths with '~' in them are treated differently in sandboxed apps.
>
> In fact the string doesn't contain a tilde. I think in summarising my issue I glossed over the exact situation, which is that I have a string which is "file://localhost/Users/<me>/Pictures/iPhoto Library/Album.xml". This string is extracted from the preferences of com.apple.iApps plist as being the path to the current iPhoto database.
>
> In my old code, which used NSString path processing methods, everything worked fine even though the string is prefixed with "file://". The presence of this prefix didn't cause any issues with accessing the file using path-based APIs. Because of that I was not really aware that it was a URL rather than just a path until I tried to update my code to use NSURLs.

I’m surprised by this. The path-based APIs were seriously handling a path beginning with file:// in the way that you expect? What were you handing this “path” off to? +[NSDictionary dictionaryWithContentsOfFile:] ?


_______________________________________________

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>)
 >Re: Sandboxing die.die.die (From: Greg Parker <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: text highlighting with CALayer and NSTextVew
  • 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