No problems :)
It's certainly worth knowing if there will be an issue or not.
-DrD-
> 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-
>
>
