On 23/08/2012, at 6:48 PM, Mike Abdullah <cocoa...@mikeabdullah.net> 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.

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

--Graham


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to