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