Re: Sandboxing die.die.die
Re: Sandboxing die.die.die
- Subject: Re: Sandboxing die.die.die
- From: Mike Abdullah <email@hidden>
- Date: Thu, 23 Aug 2012 14:11:38 +0100
On 23 Aug 2012, at 11:52, Graham Cox wrote:
>
> On 23/08/2012, at 6:48 PM, Mike Abdullah <email@hidden> wrote:
>
>> 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?
>
> Yes, it's a string representation of a URL, so using URLWithString is right here. (it's file://localhost/.....)
>
> The reason I didn't try this at first is because I was updating code based on paths, not URLs, and formerly this string was treated as a full path using the NSString paths APIs and other things that used them, such as NSFileManager. None of these APIs seemed to mind about the file:// and I wasn't even aware it was there, the path coming from the iApps preferences file and passed along to other objects based on paths.
What do you mean by “mind”? Any string is a valid path, so no path-based API is ever going to complain about the path you giving it being invalid; only that nothing happens to exist at that path.
>
> When you pass this to [URLWithFile:isDirectory:], it does end up as a malformed URL which looks like <path to somewhere in my sandbox>/file://<the rest of the above path>.
I don’t see that as an invalid URL. I assume you’ve missed out the initial file:// bit in your description. The +fileURLWithPath… methods are documented as handling a relative path as being relative to the home directory. It sees that the “path” you’re giving it doesn’t start with a slash, and so presumes it’s relative, tacking it onto the end of the home directory. (for a sandboxed app the home directory is your container)
>
> I guess this counts as "undefined behaviour" rather than trying to make the best of a programmer error, which is probably fair enough. Soooo... is it a bug? Not really, though NSURL *could* make a better stab of dealing with it than it does.
I don’t see how it could. Any path is technically valid. Yes, NSURL could spot that the string is also a valid file URL in its own right, but that’s only an educated guess. It’s always possible that you really are dealing with a folder named “file:” and if the API were to throw an exception that would break the app. If it logged a warning, that could be helpful, but also wasteful.
_______________________________________________
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