On 23/08/2012, at 9:37 AM, Graham Cox <graham....@bigpond.com> wrote:
> Trying to work around this is proving impossible with the current sandbox > implementation - there are too many opaque hacks in the system that mean you > cannot trust the URLs you get from anywhere to actually point to the right > place, and you also have to hard-code paths in your entitlements which are > extremely fragile under both localisation and system updates. (For example, > if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that > location changes, or is named differently, my app stops working. Note the > name of the iPhoto Library did subtly change between 10.7 and 10.8 - the > space is a different unicode character now). Well, I spoke too soon, and have actually solved this problem. Whether it proves to be robust I can't say, but it wouldn't seem to be any worse than our un-sandboxed app in that respect. Turns out the problem I was having with this is because of the behaviour of [NSURL fileURLWithPath:isDirectory:]. When I passed the path to the iPhoto database file (~/Pictures/iPhoto Library/Album.xml) the resulting URL was bizarrely altered to point to some non-existent path within my sandbox. In fact it looks like a bug because it ended up concatenating 'file://' somewhere in the middle of the path which makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly. I've also had to rev a fair bit of my code to work with URLs rather than paths, but that was a legacy from before URLs were more commonly used so that's not a sandboxing issue per se, but using URLs works with sandboxing whereas paths do not always it seems. I've been meaning to update this legacy code for a while, but while it continued to work had no real incentive to do it. Because the iPhoto Library lives inside ~/Pictures, and there is a general entitlement for that folder, I no longer need a special temporary exception for the iPhoto Library, so the hard-coded paths issue goes away, as long as iPhoto Library remains in this location. I look up the actual name by peeking at iApps preferences and I still need a temporary entitlement for that, so I'm still at the mercy of Apple changes to these things, but no more so than before. The other aspect to the general problem I was having, that of managing to resolve security-scoped bookmarks across sessions, I solved yesterday. Turns out the issue there is that you need to call the -startAccessingSecurityScopedResource after resolving the bookmark and leave it in that state until you are completely done with the folder (in my case that's only when the app quits). I get an exception logged when dragging and dropping, but oddly it doesn't seem to cause any problems - D&D still works fine: Anyone any thoughts on this: Artboard(70831) deny file-issue-extension /Users/grahamcox/Pictures/IMG_0899.JPG OS Version: Mac OS X 10.8 (12A269) Report Version: 8 Thread 0: 0 libsystem_kernel.dylib 0x0000000103f99efe __mac_syscall + 10 1 libsystem_sandbox.dylib 0x000000010401e4fe sandbox_issue_fs_rw_extension + 32 2 CoreFoundation 0x00000001013b77e2 __CFPasteboardIssueSandboxExtensionForPath + 130 3 CoreFoundation 0x00000001013b74e6 __CFPasteboardIssueSandboxExtensionForFileURL + 150 4 CoreFoundation 0x00000001013838b7 __CFPasteboardSetData + 1287 5 CoreFoundation 0x000000010138333e CFPasteboardSetData + 446 6 AppKit 0x0000000101bb774d -[NSPasteboard _setData:forType:index:usesPboardTypes:] + 376 7 AppKit 0x0000000101bb9020 -[NSPasteboard writeObjects:] + 1219 8 Artboard 0x000000010009b8f1 -[GCMediaBrowserController imageBrowser:writeItemsAtIndexes:toPasteboard:] + 161 (GCMediaBrowserController.m:636) 9 ImageKit 0x000000010a19a6b6 -[IKImageBrowserView(ImageBrowserDragNDropInternal) startDragNDropWithEvent:itemIndexes:] + 616 10 ImageKit 0x000000010a19f949 -[IKImageBrowserView(ImageBrowserEvents) mouseDragged:] + 1235 So unless any further issues are uncovered by testing with sandboxing, it looks like my app will now be able to adopt it with no loss of functionality, which is a huge relief. I still think the general issues surrounding the sandboxing implementation are worth discussion though. --Graham _______________________________________________ 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
