Re: (solved?) baseURL problem with +fileURLWithPath:
Re: (solved?) baseURL problem with +fileURLWithPath:
- Subject: Re: (solved?) baseURL problem with +fileURLWithPath:
- From: John Joyce <email@hidden>
- Date: Tue, 18 May 2010 13:01:02 -0500
On May 18, 2010, at 12:39 PM, email@hidden wrote:
> Content-Type: text/plain; charset=us-ascii
>
> First, the first 2 characters need to be // and not / for it to be a valid resource specifier. The 10.6 Overview states it will fail to create a NSURL. Look at the class reference. Why the base is set to your binary maybe just a bug in 10.5. So you don't go nuts, just temp fix the string and then execute your code to see if the originating pseudo URL is your prob.
>
> -Tony
Yes, the resource specifier should be protocol://pathtoresource
a file URL uses file://path
a path to a file always becomes absolute here.
/ is root directory of the volume in a file path in unix
thus, it should have the following appearance: (3 slashes after the colon)
file:///absolute/path/to/file
You can quickly test such file paths for validity in Safari, they should open the resource or give an error there.
paste this into Safari's address bar and press enter/return:
file:///Users/
Then try this:
file:///Applications/Safari.app/Contents/Resources
As you can see this should work within a bundle as well.
Safari is probably handing this off to the OS and doing basically what the command line does with the tool named open
If your resource is not revealed by the OS in some manner here then it is likely not available via NSURL or it is a malformed path.
[to OP] BTW, as JOAR said, you were simply not using the API correctly. Please do not whine (as in the original post) as this is not helpful._______________________________________________
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