I am not sure what you mean by the failure, could you explain please? In my experience, if you have read-write sandbox access to a url, you can create bookmark with and without the NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess flag, and it will create different NSData objects. And if you have read-only sandbox access to a url, the both bookmarks created with and without the flag, will produce identical NSData objects. That’s the point of my method, to test the potentially read-write NSData against the afore-known read-only NSData.
And as always, my design is asked to be reconsidered. No one wants to reconsider design of the sandbox itself, that *IS* creating so much pain in the ass for everyone :) I need this bookmark access testing because the sandbox is buggy on OSX Mavericks and I need to work around it. Namely, unlike previously, only read-only access is granted to a folder if you open certain folders by dragging them to your app’s *window* (as opposed to dragging it to the app’s icon in the Dock or opening via NSOpenPanel). BTW this bug affects many apps in the App Store which need to write and delete files in folders. I have already filed this bug to Apple and in the meantime, I need to give some kind of instruction to the user. To do this I need to know if there is no access due to file permissions (normal case) or due to sandbox (Mavericks bug). On Wed, Nov 13, 2013 at 7:51 PM, Mike Abdullah <mabdul...@karelia.com> wrote: > > On 13 Nov 2013, at 11:46, Oleg Krupnov <oleg.krup...@gmail.com> wrote: > >> Thanks for new info, but no, unfortunately, this NSURLIsWritableKey >> cannot discriminate between "not writable due to file permissions” and >> “not writable due to sandbox” cases. The both cases are "not writable" >> for the NSURLIsWritableKey. >> >> I’ve found another workaround but not sure how reliable it is, because >> the bookmark data is an opaque object and its implementation is not >> clear. >> >> Namely, when I need to test a URL for writability, I create two >> bookmark datas from the url using the -[NSURL >> bookmarkDataWithOptions:…] method. The first is created with >> NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess option, and >> another one without it. >> >> Then I test whether the two NSData objects that I obtain are >> byte-by-byte identical (-[NSData isEqualToData:]), and if yes, then I >> assume this is a read-only bookmark. Otherwise, I assume this bookmark >> is writeable, from sandboxing point of view. >> >> The weak point of this method is the assumption that the obtained >> bookmark NSData is always identical if the path and its sandbox access >> mode do not change. I could theoretically get a false positive if I >> get a different NSData object while the url is still read-only. The >> false negative seems less likely (that I get an byte-by-byte identical >> NSData object while the URL is not read-only any more.) >> >> If I could be sure that bookmark data doesn’t involve any changeable >> data (like time stamps etc.), this could be a reliable method. > > Hmmm, that sounds very ropey to me. In my experience > NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess has little to no effect > on how the file is handled at a write level. i.e. if you have read-only > access to the file, creating the bookmark will fail since it tries to achieve > write access to the file. > > I think you should back up and consider your design. The sandbox isn’t really > designed to be tested in this manner. Instead your app is supposed to track > things and have a decent idea of which resources it ought to have access to, > and which not. > _______________________________________________ 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
