On 23 Oct 2012, at 19:13, Richard Somers wrote:

> I do not understand what is going on with an application's sandboxed 
> container or Data directory.
> 
> NSHomeDirectory for an OS X sandboxed app points here.
> 
>     ~/Library/Containers/<bundle_id>/Data
> 
> The sandbox Data directory is pre-populated with items.
> 
>     Data/Desktop     (Alias)
>     Data/Documents
>     Data/Downloads   (Alias)
>     Data/Library
>     Data/Movies      (Alias)
>     Data/Music       (Alias)
>     Data/Pictures    (Alias)
> 
> So here are some of the unusual things.
> 
> 1. If you specify "No Access" to the Music, Movies, Pictures, or Downloads 
> folders for the App Sandbox you can still save a document to those folders. 
> So much for the sandbox.

What exactly do you mean by “save a document” here?
> 
> 2. When a file is saved to the Documents folder in a save dialog, the file is 
> actually saved to ~/Documents not Data/Documents. So what is Data/Documents 
> for?

Yes, the open/save panels automatically translate any locations form within the 
container to outside. Anything within the container is not intended for regular 
users to see.

Your app could generate “documents” which get stored on disk in the Documents 
folder, but provide its own UI for managing that data perhaps, rather than the 
standard open/save panel approach.
> 
> 3. Data/Documents is pre-populated with an iChat file alias. What is that for?

Does it matter?
> 
> 4. Local log files go in Data/Library/Logs but this location is not visible 
> from Console app. So all local log files are visible from Console except for 
> apps that are sandboxed. How can a user see local sandboxed log files?

How are you generating these logs?
> 
> 5. Data/Library/Preferences is pre-populated with a bunch of preference plist 
> file aliases. One of the items is an alias to com.apple.iWork.Pages.plist. 
> Why would my app need default access to the Pages preference plist file? This 
> seems like a violation of sandboxing.

Some other apps have relied upon this, I would guess. Can your app actually 
access that plist while running though? Just because it’s there as a symlink 
doesn’t necessarily mean the app has access to it.


_______________________________________________

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

Reply via email to