At 12:02 Uhr -0700 22.09.2011, cocoa-dev-requ...@lists.apple.com wrote:
One can only hope that this is because App
Sandbox is currently not fully baked.
Otherwise, how would something like Xcode work
sandboxed? ¬ÝAn .xcodeproj contains zillions of
relative paths to files that the user,
On Wed, 21 Sep 2011 13:26:20 +0800, Peter N Lewis said:
The explicit entitlement to read a file following an open/drag exists
only until the application quits (a fragile exception exists in using
URLs stored into the restorable state archive, but even that won't work
long term). Thus keeping
The explicit entitlement to read a file following an open/drag exists
only until the application quits (a fragile exception exists in using
URLs stored into the restorable state archive, but even that won't work
long term). Thus keeping references to files is essentially impossible
(long term) in
On Thu, Sep 22, 2011 at 10:48 AM, Sean McBride s...@rogue-research.com wrote:
Either App Sandbox is unfinished, or Apple is taking us towards of word of
iFart-type apps only.
Sandbox is not yet finished. On the dev forums, the sandbox engineers
(or DTS representatives) have been rather
The explicit entitlement to read a file following an open/drag exists
only until the application quits (a fragile exception exists in using
URLs stored into the restorable state archive, but even that won't work
long term). Â Thus keeping references to files is essentially impossible
(long
On Sep 22, 2011, at 10:48 AM, Sean McBride wrote:
On Wed, 21 Sep 2011 13:26:20 +0800, Peter N Lewis said:
The explicit entitlement to read a file following an open/drag exists
only until the application quits (a fragile exception exists in using
URLs stored into the restorable state
I don't think that the access rights are permanent, the only way to enable
sandboxing for this kind of app would be to use a temporary exception
entitlement giving your app access to the whole file system (not sure if Apple
will like that for the Mac App Store, though).
You can copy your
I don't think that the access rights are permanent, the only way to enable
sandboxing for this kind of app would be to use a temporary exception
entitlement giving your app access to the whole file system (not sure if
Apple will like that for the Mac App Store, though).
That would suck
On Sep 19, 2011, at 9:26 PM, Peter N Lewis pe...@stairways.com.au wrote:
Questions:
* When the user opens/drags a file to me application, is the explicit
entitlement to read that file that I'm granted permanent? Will it remain
across launch/reboots?
Nope. This is a known limitation.
On 20 Sep 2011, at 11:30, Torsten Curdt wrote:
I don't think that the access rights are permanent, the only way to enable
sandboxing for this kind of app would be to use a temporary exception
entitlement giving your app access to the whole file system (not sure if
Apple will like that for
On 2011 Sep 20, at 08:48, Keith Duncan wrote:
Any URLs an application encodes into it's restorable state archive (resume
support is required for any open windows for automatic termination to
actually quit an application) will be accessible in terms of sandboxing when
the application is
On 20 Sep 2011, at 19:35, Jerry Krinock wrote:
At first I was thinking that this would give my app a permanent entitlement
to whatever URL was selected. But what if the user restarts and clicks
Don't restore windows. Wouldn't that break it?
Based on what I have been told and my own
Thanks for the various answers, here is a summary:
The explicit entitlement to read a file following an open/drag exists only
until the application quits (a fragile exception exists in using URLs stored
into the restorable state archive, but even that won't work long term). Thus
keeping
Questions:
* When the user opens/drags a file to me application, is the explicit
entitlement to read that file that I'm granted permanent? Will it remain
across launch/reboots?
* How do I deal with files that I already have a reference to if I enable
sandboxing in a future version?
* What
14 matches
Mail list logo
