STS.app on Mac 10.12.1 always creates a new org.springsource.sts folder in .eclipse

问题

I've downloaded and installed STS 3.8.2 on my Mac (10.12.1). Each time the STS.app file is launched, it creates a new org.springsource.sts_3.8.2.RELEASE_########_macosx_cocoa_x86_64 folder under the hidden .eclipse folder (the hashes are there because I have MANY of the same folder with the numbers in the hash area being the only difference). In doing so, the default workspace and all plugins I installed the last time it was running are wiped out (because they exist in the previous #### folder).

I've tried installing the previous 3.8.1 and 3.8.0 version, but they are doing the same thing. My previous STS install started at 3.7 and has been upgraded to 3.8.1, but will not update anymore because of update errors that I can't seem to fix (none of the StackOverflow "fixes" have worked for me).

Is there a way to have STS not create a new folder (instance) in the .eclipse folder each time it launches? If so, how?

回答1:

This got reported to STS and is documented here: https://issuetracker.springsource.com/browse/STS-4406

The corresponding bug at Eclipse is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=507328

To cut a long story short:

This is caused by macOS Sierra Gatekeeper App Translocation, a security feature that moves the app into a private read-only location for security reasons. Therefore Eclipse/STS creates a folder for its configuration in that location that you described above.

Since macOS Sierra does the app translocation again after every restart, Eclipse/STS doesn't know anything about the "old" configuration area anymore and creates a new one. As far as I can see, there is no way for Eclipse/STS to distinguish between a separate install and a newly translocated app... :-(

The workaround is:

A) Move STS.app into a different location on your disc after unpacking the tar.gz archive (using the Finder, not the command line). If you move it to "Applications", for example, everything works as before (no app translocation happens in that case).
B) You could also start Eclipse/STS by clicking on the Executable (in STS.app/Contents/MacOS). That also doesn't cause app translocation and therefore everything is fine.

回答2:

As this bug — alternatively unfortunate side-effect of Apple security measures — still exists in STS 3.9.8 (I assume also in 3.9.9) and the Eclipse bug report in the previous answer is closed as a duplicate of Workspace Preferences Do Not Persist on MacOS Sierra that, while being marked as "solved, actually in itself actually do not solve this dislocation issue — in that moving the app to /Applications or having a signed DMG, both making no difference — the info missing is that one can turn off App Dislocation on an app by app basis by using the "xattr" command in the Terminal, that works upon extended file attributes.

Use the command