Well, the OS definitely believes the app is sandboxed. The full URL I get for ~/Documents/ is in fact ~/Library/Containers/<bundle id>/…. blah blah
I did a clean build and changed the bundle ID as well as discarding the container, but no, it just makes a new container with the new bundle ID. This is exasperating, I can’t see where it could be getting such a notion from. Sandboxing is OFF in Xcode’s ‘Capabilities’ section, and AFAICS no .entitlements file is added to the build. Th eonly ‘funny’ I have in my info.plist is an entry for NSUbiquitousContainers, since I wanted to allow access to the user’s iCloud documents. I thought that setting allowed this without sandboxing, not that it snuck sandboxing in by the back door. I will check and see whether that’s a red herring. —Graham > On 28 Jan 2016, at 2:41 PM, Roland King <[email protected]> wrote: > > have you checked your info.plist file just to be certain damned sure Xcode > hasn’t slipped in something nasty whilst you weren’t looking? I’d actually > look at the one in the app bundle you’re running because I’m paranoid like > that. > > > >> On 28 Jan 2016, at 11:17, Graham Cox <[email protected]> wrote: >> >> I did say that, and the app definitely isn’t sandboxed (it’s running from >> Xcode also). However, I just noticed that I get this in the log when the app >> receives the error: >> >> >> 28/01/2016 12:26:35.124 PM sandboxd[127]: ([19475]) MyApp(19475) deny >> file-write-create /Users/grahamcox/Desktop/Untitled_0001.png _______________________________________________ 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]
