Community
Participate
Working Groups
I am using Eclipse JEE Neon.1 package, start it up on my macOS Sierra machine and install an additional feature from an update site. That all works fine. BUT: When I start Eclipse the next day, the global settings are lost as well as my newly installed feature. This is a dramatic problem from my point of view. Observations: - when I install the additional feature, the progress tells me that Eclipse seems to install ALL installed features again - a new folder in ~/.eclipse is being created, for example: org.eclipse.platform_4.6.1_1742145858_macosx_cocoa_x86_64 - the additional plugin is being put into this folder (together with configuration data) - the next day, a new folder in ~/.eclipse is being created, containing fresh configuration data and no additional plugins Why does this happen? Any idea what is going wrong here?
I tried this with Eclipse 4.7M3 (SDK) and it looks like: - starting Eclipse by clicking on "Eclipse.app" (the macOS way of doing things), this new config folder is being created and additional plugins are being installed in there. - starting Eclipse by clicking "eclipse" in "Eclipse.app/Contents/MacOS/" there is no new config folder being created and additional plugins are being installed into "Eclipse.app/Contents/Eclipse" Why is that different?
Pascal, do you have any ideas on why this is happening? I would move to p2 but the difference in behavior between launching with "Eclipse.app" vs the eclipse binary seems to indicate some issue with the native launcher.
Any new insights on this?
I tried to find out more, here are my results: This seems to be related to App Translocation in macOS Sierra. If you start the macOS app as regular app from somewhere on your disc, the application gets translocated into a random private location and started from there. This is a security enhancement of macOS Sierra. This translocation seems to confuse Eclipse somehow. The osgi.configuration.area is then created in another random location under ~/.eclipse/. And that randomly chosen area seems to change every day or so. If this translocation doesn't happen (for example if the app is moved to the Applications folder of macOS), then everything is just fine and the osgi.configuration.location is set to the location of the app (as usual). If you start Eclipse not by clicking in the Eclipse.app icon, but you start the executable inside of the package (Eclipse.app/Contents/MacOS/eclipse) then macOS Sierra doesn't translocate the app either and everything is fine. That seems to be the reason why it makes a difference (as mentioned in the comment above). So it looks like there is something going wrong at startup time when the app is being translocated by macOS Sierra.
(In reply to Martin Lippert from comment #4) We may need to provide a signed DMG to distribute Eclipse on the Mac if we want to avoid the randomized path (see bug 461670 comment 2).
(In reply to Martin Lippert from comment #4) > If this translocation doesn't happen (for example if the app is moved to the > Applications folder of macOS) Is it that simple to workaround the translocation? You opened the app by clicking the Eclipse.app icon in the /Applications folder and everything was fine?
> We may need to provide a signed DMG to distribute Eclipse on the Mac if we > want to avoid the randomized path (see bug 461670 comment 2). Not sure about that. At least this happens for a signed .app package (officially signed with an Apple Developer certificate). Not sure if a signed DMG changes the behavior.
> > If this translocation doesn't happen (for example if the app is moved to the > > Applications folder of macOS) > > Is it that simple to workaround the translocation? You opened the app by > clicking the Eclipse.app icon in the /Applications folder and everything was > fine? From what I read, yes, that is enough. In that case the app is regarded as "installed". That is what I read and what I tried. Although I should mention that the .app package was signed with a dev certificate from Apple.
The most interesting (and important) question from my end is: --> Where does the osgi.configuration.area gets configured to point to this random location in ~/.eclipse/ If we can fix this, it should work all the cases, independent of the app being translocated or not. Tom, do you know where this happens? Would love to take a look at the code that decides this.
(In reply to Martin Lippert from comment #9) > The most interesting (and important) question from my end is: > > --> Where does the osgi.configuration.area gets configured to point to this > random location in ~/.eclipse/ > > If we can fix this, it should work all the cases, independent of the app > being translocated or not. > > Tom, do you know where this happens? Would love to take a look at the code > that decides this. Checkout the method: org.eclipse.equinox.launcher.Main.computeDefaultConfigurationLocation()
(In reply to Martin Lippert from comment #7) > > We may need to provide a signed DMG to distribute Eclipse on the Mac if we > > want to avoid the randomized path (see bug 461670 comment 2). > > Not sure about that. At least this happens for a signed .app package > (officially signed with an Apple Developer certificate). Not sure if a > signed DMG changes the behavior. From what I read, a signed DMG will indeed turn-off the Gatekeeper Path Randomization.
Thanks for the pointer into the code, Tom, much appreciated. I debugged this today and I think there isn't much that we can do here. macOS Sierra has Gatekeeper Path Randomization. That is activated in very specific situations (if you download the Eclipse zip file, extract it, and start Eclipse right there, for example). If it is activated, Gatekeeper Path Randomization copies the app to a private randomized read-only area on the disc and starts it from there. As a consequence the Equinox Launcher detects that the install location is read-only and creates a matching folder in the users home in ~/.eclipse/. It uses a hash of the install dir as part of the name. All good so far. The bad part of this is that the Gatekeeper Path Randomization happens after every restart of your machine again (to a new, different location). Maybe this "do the path randomization again" thing is triggered by other events, too. This means, from the Equinox launcher perspective, this looks like a new install and a new matching config area will be created - and all old installs and settings are lost. I don't see a good way to solve this in the launcher, since I have no idea how to differentiate between a newly installed app and a newly path randomized version of the app. Solutions that avoid the Gatekeeper Path Randomization are: - move your Eclipse.app via the finder to a different location - create a signed DMG image and ship that instead (since that requires people to move the app to a new location on disc) - start Eclipse via the executable (instead of the macOS app bundle) Therefore I will mark this as closed and "not eclipse". And will post a note to the cross-project list to make people aware of this issue.
*** This bug has been marked as a duplicate of bug 461670 ***
*** Bug 506797 has been marked as a duplicate of this bug. ***
(In reply to Martin Lippert from comment #12) > macOS Sierra has Gatekeeper Path Randomization. That is activated in very > specific situations (if you download the Eclipse zip file, extract it, and > start Eclipse right there, for example). This happened to me with an Oxygen RC and was a pretty frustrating experience, since every thing looks good at first, but the problem started only when I resumed my work on the next day. > I don't see a good way to solve this in the launcher, since I have no idea > how to differentiate between a newly installed app and a newly path > randomized version of the app. I think it is very much desirable to detect if the translocation is active and warn the user accordingly. Maybe it would be even better to abort the start of the application, since it's clear that it WILL create problems. It seems there are at least 3 options to detect if translocation is enabled: - Use <Security/SecTranslocate.h> from the 10.12 SDK - Use custom code that doesn't require the 10.12 SDK, like described here: http://lapcatsoftware.com/articles/detect-app-translocation.html - Use a hack, like checking if the starting path contains the string "AppTranslocation" (the translocated path looks like "/private/var/folders/n6/drcyfyts2w5b7cq0bl4mv2km0000gn/T/AppTranslocation/7F0451C2-1F69-4CF7-AE4C-9BA402FBB7B4/d/Eclipse\ 4.7RC2\ I20170524-2000.app" on my system) > Solutions that avoid the Gatekeeper Path Randomization are: > - move your Eclipse.app via the finder to a different location > - create a signed DMG image and ship that instead (since that requires > people to move the app to a new location on disc) > - start Eclipse via the executable (instead of the macOS app bundle) Just for the record, I tried to use "xattr" to remove the flag "com.apple.quarantine", but that didn't seem to be enough, I had to move the application using the finder. > Therefore I will mark this as closed and "not eclipse". And will post a note > to the cross-project list to make people aware of this issue. I think lots of confusion and effort can be saved on the user side if a warning was provided. Does that sound feasible or/and reasonable? Should I open a new ticket?
*** Bug 518303 has been marked as a duplicate of this bug. ***
Sounds like a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=507328 And the answer is likely "due to App Translocation". See also: https://lapcatsoftware.com/articles/app-translocation.html
Oops. I posted that previous comment to the wrong issue. Is there any way to delete comments?
(In reply to Sam Brannen from comment #18) > Oops. I posted that previous comment to the wrong issue. > > Is there any way to delete comments? No.
