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

[David DeHaven]

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