On 23 Aug 2012, at 11:52, Graham Cox wrote: > > 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.
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 (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
