• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sandboxing die.die.die
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing die.die.die


  • Subject: Re: Sandboxing die.die.die
  • From: Kyle Sluder <email@hidden>
  • Date: Thu, 23 Aug 2012 17:11:44 -0700

On Thu, Aug 23, 2012, at 04:33 PM, Graham Cox wrote:
> 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".

Just FYI, this is not a valid URL. The space in "iPhoto Library" needs
to be percent-encoded.

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

Colons are legal characters in filenames. The Finder converts them to
slashes for display. (Though I wonder if the underlying HFS filesystem
plugin converts them *back* into colons for storage in the directory
tables.)

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

In general, no. You should not use +URLWithString: to create an NSURL
from a filesystem path. Use +fileURLWithPath:isDirectory: instead. It
handles cases like percent-encoding.

--Kyle Sluder
_______________________________________________

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

  • Follow-Ups:
    • Re: Sandboxing die.die.die
      • From: Graham Cox <email@hidden>
References: 
 >Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Jens Alfke <email@hidden>)
 >Re: Sandboxing die.die.die (From: Kyle Sluder <email@hidden>)
 >Re: Sandboxing die.die.die (From: Alex Zavatone <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Greg Parker <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Sandboxing die.die.die
  • Next by Date: Re: Sandboxing die.die.die
  • Previous by thread: Re: Sandboxing die.die.die
  • Next by thread: Re: Sandboxing die.die.die
  • Index(es):
    • Date
    • Thread