Re: URLByResolvingBookmarkData not case sensitive
Re: URLByResolvingBookmarkData not case sensitive
- Subject: Re: URLByResolvingBookmarkData not case sensitive
- From: Trygve Inda <email@hidden>
- Date: Tue, 06 Jan 2015 08:25:03 -0800
- Thread-topic: URLByResolvingBookmarkData not case sensitive
> 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.
What then is the best way to do what I need?
I am saving a bookmark to a file and later on I need to display the filename
associated with that Bookmark.
Currently I am getting the path and taking the last component, but it seems
that when the filename's case has been changed by the user, that path
received does not change so I am left with a name that does not match
because the case is different.
_______________________________________________
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