• 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: URLByResolvingBookmarkData not case sensitive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: URLByResolvingBookmarkData not case sensitive


  • Subject: Re: URLByResolvingBookmarkData not case sensitive
  • From: Fritz Anderson <email@hidden>
  • Date: Mon, 05 Jan 2015 11:15:12 -0600

On 5 Jan 2015, at 10:11 AM, Trygve Inda <email@hidden> wrote:
>
> I am using URLByResolvingBookmarkData .
>
> If I make a Bookmark to a file:
>
> /Volumes/Macintosh HD/Documents/MyFile.txt
>
> and later resolve it with URLByResolvingBookmarkData, I get the original path as expected.
>
> Then if I change the filename to MYFILE.txt in the Finder and resolve the bookmark again, the URL is still the mixed-case path above instead of the new uppercase file path.
>
> I would expect to get the current path in a case sensitive way.


The following assumes that your problem is that the pathname hasn’t been updated, not that the reconstituted URL no longer gives access to the desired file. If the bookmark no longer works, then ignore the rest of this.


What you expect is plausible, but it’s also plausible that it’s not in the API contract: The most that’s directly promised is that the bookmark will be as robust as possible _in gaining access_ to a volume, directory, container, or file. Your expectation isn’t disclaimed, but I don’t think Foundation promises to make good on it.

So long as the grants-access promise is kept, it’s not necessary to report the identical URL string you’d get if you passed the current path to +fileURLWithPath: :

* We don’t know whether alias resolution even looks at the string you originally put in the bookmark container. It’s an implementation detail; the string you gave might be kept only as a courtesy (or a last resort). We don’t know, and I don’t think we’re supposed to care.

* In the Mac’s default case-insensitive HFS+, correcting for case is pointless. The string you asked the container to contain is still fit for purpose.

* Presentation to the user don’t enter into it. Path (and URL) strings have never been safe for presentation to users. (To take one example, standard system directories are localized, but the BSD paths never change from their US-English names.)

I’m not saying the documentation disclaims your interpretation, just that it leaves it open to Foundation’s doing what you’re seeing.

	— F


_______________________________________________

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: URLByResolvingBookmarkData not case sensitive
      • From: Trygve Inda <email@hidden>
References: 
 >URLByResolvingBookmarkData not case sensitive (From: Trygve Inda <email@hidden>)

  • Prev by Date: Re: Blurry is the New Sharp
  • Next by Date: Re: Rearranging NSOutlineView via drag-and-drop
  • Previous by thread: URLByResolvingBookmarkData not case sensitive
  • Next by thread: Re: URLByResolvingBookmarkData not case sensitive
  • Index(es):
    • Date
    • Thread