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

[Nicholas Rahn]

> > In my app, I have an export dialog where the user can select the file to
> export as well as choose some other export options. In that dialog, after
> the user has selected the file to export (via the file selection dialog), I
> display the full path to the file that was returned from the file selection
> Dialog.
> >
> > So, if I understand you correctly (sorry, I haven't had time to verify
> this myself), with this change, passing in "user.home/Documents" to the
> file dialog, the user will see "~/Documents" in the file dialog, but the
> full Container path will be returned as the selected file. So in my export
> dialog, the user would see the full Container path, even though the file
> selection dialog had shown a normal ~/Documents path?
>
> If you're using FileDialog (or some variant that eventually boils down to
> NSSavePanel) then your app will continue to function properly. If you're
> using a custom dialog then you'll need to switch to FileDialog (or
> variant...) since NSSavePanel is what triggers powerbox to do it's thing,
> if NSSavePanel is not invoked to choose the exported file then your app
> will never be granted permission to write to the file (unless you incant
> some other, more complicated, voodoo magic).
>
> 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.

Side note: I'm using SWT and it boils down to the NSOpenPanel and
NSSavePanel.


> > Additionally what's not clear is (again, sorry, I haven't had time to
> verify this myself), if I do export the file to the Documents directory
> under the Container path, where does the file actually get saved? In
> /Users/nick/Documents or in
> /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the
> Container's Documents folder, for other applications (Finder, Excel,
> Preview, etc) will it be visible in /Users/nick/Documents ?
>
> If you look in the app container you'll see that the Data directory
> returned by NSHomeDirectory() is set up with symlinks back to the users
> home directory, so when you access files in those directories you're
> accessing the correct files. IOW,
> ~/Library/Containers/com.blah.someapp/Data/Documents is the same as
> ~/Documents, the system does all this for you when the app container is
> created.
>
>
Actually, the Documents directory in the Container is NOT a symlink. It is
an actual directory.  So the 2 key questions are:

1. Is there a way to convert from
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
~/Documents/somefile.csv to display in the UI for the user?

2. If the file gets saved to
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
other applications (such as Excel) access the file from
~/Documents/somefile.csv ?


> > @Brent - you wrote:
> > "As it is now, apps needing to write app-specific data would need to
> special-case for the App Sandbox and go find the Container directory, since
> $HOME is not accessible (and only becomes accessible if the user interacts
> with a FileDialog)."
> >
> > Well, I already had to special case where I write app-specific data for
> each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
> is really cross-platform is going to have some platform specific code and
> platform specific jvm-launching/packaging, if they want to do things the
> recommended way for that platform. A sandboxed Mac version was just another
> special case.  For that, I use the AppBundler fork to launch the JVM and
> set some MAS specific properties so that I know that I'm running in the Mac
> sandbox and where the Container directory is. Then the right
> platform-specific initialization code in my app can be used to build the
> app-specific data in the right place.
>
> That's the unfortunately truth of modern (secure) applications, each
> platform has it's own way of doing things. Have you tried Windows 8 yet?
>
> Changes like what Brent is proposing is helping to keep Java consistent
> with the ever evolving app model, which is ultimately a good thing.
>
>
Platform specific code for any Java desktop app is inevitable. What bothers
me about this proposed change is that you're taking away a useful property
(the user's $HOME) and replacing it with something that, to me, is best
done in an app's platform specific code, not in the JDK's. And I still need
to know the user's $HOME, since the answers to my 2 questions above are
probably 'no', so I'll have to add more to my app's Mac sandbox-specific
code to get it.

Windows 8: I do have a few people using my software on W8, but I have not
done anything specific for it. That is to say, I do the same platform
specific stuff as I do on W7.

Nick