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

[Steven Wilson]

In the versions of Mac OS X that I'm looking at (Lion and Mtn Lion)  
the Documents folder inside the sandbox is NOT a symlink. Desktop,  
Downloads, Movies, Music and Pictures ARE all symlinks, but not  
Documents, so "~/Library/Containers/com.blah.someapp/Data/Documents"  
is not the same as "~/Documents". Someone correct me if I'm wrong but  
that's what I'm seeing.

Steve Wilson

On Sep 11, 2013, at 10:39 AM, macosx-port-dev-request at openjdk.java.net  
wrote:

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