On Feb 16, 2012, at 8:57 AM, Sean McBride wrote: > It looks like good progress, and is now documented here: > > <https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSURL_Class/Reference/Reference.html> > > But I still don't see how something like Xcode could be made to work. The > Xcode file format stores relative paths, not bookmark data. If one downloads > an Xcode sample project from the web, what would Xcode need to do? Show an > NSOpenPanel to confirm that, yes, each source file may be accessed? (No > doubt, Xcode gets to be exempt, it's just an example.)
In DMG Canvas, I do the same thing. I store both a relative and absolute file path. It prefers to resolve by relative path, otherwise it uses the absolute path. I've been looking at it more, and I think there's still a gaping problem here. I thought the "relativeToURL" parameter was the key to this, but I can't get it to work how I expect, so I don't think it's the solution. -- My experiments without relative URL -- 1) I have an image file on my desktop, and I made a bookmark to it. Resolving it works. 2) If I take that image file and move it elsewhere or rename it, the bookmark still resolves (by file id). 3) If I move that image file off of the desktop, but add a new image file with the same name to the desktop, the bookmark resolves to the new file on the desktop. 4) If the bookmark was created with NSURLBookmarkCreationPreferFileIDResolution and do the same steps as in #3, it *still* resolves to the new file on the desktop. That seems definitely wrong. It should resolve by file id, so it should refer to the original file which was moved elsewhere. -- My experiments with relative URL: -- Documentation seems to be scant, but I'm assuming the "relativeToURL" parameters are for storing and resolving bookmark data relative to a URL such that, they prefer to resolve with the same relative path to the given URL. In Xcode and DMG Canvas, this would be relative to the project/document. 1) So what I did was make a document on the desktop. I then added to this document a bookmark to an image file also on the desktop, setting "relativeToURL" to the document's URL. 2) When reopening the document, if I resolve the bookmark with a nil relativeToURL, it resolves properly. If I pass the URL of my document as relativeToURL, it resolves properly. If I pass in any arbitrary nonsense for the URL, it still resolves. 3) If I now take both the document and the image file and move them off of the desktop into another parent, even after renaming the image file, when passing a non-existent path to relativeToURL when resolving the bookmark *still* resolves the bookmark to the file, so it must be doing that by file number (since by path would have failed). 4) Now, the real question, what if there are two possibilities when resolving the bookmark? If I have the document on the desktop, the image file on the desktop, and I add to the document a bookmark to the image file, using the document's url as the relativeToURL parameter, move both the document and the image file off of the desktop to another parent directory, then create another image file on the desktop with the same name as the image file which previously was there, when I open the document and pass its current URL as relativeToURL when resolving the bookmark, it resolves to the file *on the Desktop*, NOT the original image file which resides in the same folder as the document. That surely seems wrong to me. Simply put, I don't think bookmarks can do what relative file paths could before. That's even before security gets involved. Given that the sandbox requires using URL bookmarks, and bookmarks can't resolve relative paths like this, it seems to me there's no possibility this could work. Please correct me if I'm wrong. -- Seth Willits _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
