On Aug 21, 2012, at 20:47, Graham Cox <graham....@bigpond.com> wrote:
> Is sandboxing the MOST HATEFUL and useless API Apple have ever created? I > can't think of a worse one in 30 years.... > > > Anyway ranting aside, > > I have a browser which allows the user to add folders to a source list and it > then scans that folder for image files and displays them, including in any > subfolders. The user can select subfolders to narrow down the list of images. > > When the app is quit, the list of folders is saved so that it can be restored > next time. Previous to sandboxing, that was easy. > > Now, it's a seriously difficult proposition. Here's what I'm doing: > > The user adds folders to the browser using the standard NSOpenPanel, so the > URL is automatically allowed by the sandbox, and can be bookmarked using a > security scoped bookmark. I've added the entitlement to allow app-wide > security-scoped bookmarks to work. > > Next session, the saved bookmarks are resolved and the browser UI restored. > That now works (after much hair-pulling). > > > Now, whenever a security-scoped URL must be accessed, you have to bracket > that with -startAccessingSecurityScopedResource and > -stopAccessingSecurityScopedResource, which in itself is painful because this > method isn't available prior to 10.7.3, so you have to additionally check > whether the URL responds to that selector, but no matter, I'm jumping through > that flaming hoop OK. (I assume that my users on 10.7 earlier than 10.7.3 > will just have to put up with the fact that none of this will work at all. > Thanks Apple). > > The problem is that all of the files and folders INSIDE the folder created > from the security bookmark are being disallowed by sandboxd despite doing > this, presumably because those URLs don't contain the magic sauce that allows > it to work - they are created by scanning the parent folder. Apparently URLs > within a scoped folder don't inherit the ability to allow access using these > methods. Fixing this is going to be extremely hard - a URL is supposed to > encapsulate all of the information about the location of a file without > reference to another URL elsewhere that happens to be the folder which > contains it (and which does have the magic sauce). > > It is clearly impractical to save a security bookmark for every single file - > there can be tens of thousands - and for the case of adding the folder using > the NSOpenPanel it works OK, so surely there has to be a way to propagate the > security access from a folder to all of the folders and files it contains? > > Or is this a use-case that once again has been overlooked in the unseemly > rush to push sandboxing on us? > That's really bad news. I have a synchronization app on the App Store and I was hoping to update it with those security-scoped URLs but if it doesn't work for the content of folders, then I'm hosed. Have you filed an enhancement request? It might well be a short sightseeing from Apple as the whole sandboxing enchilada seemed to be something that was quickly put together without much thought. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com _______________________________________________ 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
