Ok, I've tried this out with my app in the sandbox. I can confirm that opening a file dialog (NSSavePanel underneath), with a directory pointing to the Container's Documents directory (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the standard ~/Documents directory selected. If you then select a file there, say 'selected-file.txt', click OK, the dialog will return the path ~/Documents/selected-file.txt. Since I have the com.apple.security.files.user-selected.read-write entitlement in my application, I can subsequently write to this path, and the file is written in ~/Documents/selected-file.txt, not in the Container's Documents directory.
So this clears up my questions about this patch. Thanks for helping me through it. Cheers, Nick On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven <david.deha...@oracle.com>wrote: > > >>> The bottom line is, if what you have now allows you to write to > >>> ~/Documents and you're sandboxed then this change should not > >>> affect your application at all, except maybe in the UI if you're > >>> displaying that path to the user. The user won't notice the > >>> difference otherwise. > >> > >> My users *will* notice because I display this path in the export dialog, > >> along with the other export options they can use. > > > > If the path displayed is coming from the selected file, then it will > continue to show the correct path. > > I don't think I was clear on that comment... if you're building the path > from say System.getProperty("user.home") + "/Documents/blah" and showing it > to the user, then that's a problem. If you're showing paths returned by the > open/save panels then you're fine, the user will never see the container > path. > > -DrD- > >