Re: Sandboxing die.die.die
Re: Sandboxing die.die.die
- Subject: Re: Sandboxing die.die.die
- From: Graham Cox <email@hidden>
- Date: Fri, 24 Aug 2012 09:33:31 +1000
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.
In updating the code to use NSURLs, passing this string to [NSURL fileURLWithPath:isDirectory:] gave me an unexpected result. Now I understand the full range of behaviour of that method, it makes a lot more sense, though I'm not entirely sure that the resulting URL (which certainly did not point to the right file) could ever be valid, because the "file://" prefix ends up in the middle of the resulting path. It's being treated as a relative URL (which it isn't). OK, I accept Mike's argument that there *could* be a folder called "file:", or at least that would be legal in terms of general URLs, though not in terms of the Mac File System which I believe forbids colons for legacy reasons, though I doubt that NSURL bothers to take that into consideration.
So I think I'm correct to be using [NSURL URLWithString:] here (tell me if that's not right!) and that does point to the right file and everything is now working.
--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