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
