On 5 Jan 2015, at 10:11 AM, Trygve Inda <cocoa...@xericdesign.com> 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 (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
