RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Nicholas Rahn]

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.dehaven at 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-
>
>