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

Question

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?

Lorri

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

Amalia

Thank you. I'll try moving it to the Applications folder. I had moved it from Downloads to the root of my user folder and that didn't work. – Lorri

One final note. The STS.app file itself has to be put into the Applications folder. I moved the entire sts-bundle folder into Applications and had the same problem...But just STS.app in the Applications folder works. – Lorri

Yes, you have to move the STS.app bundle itself and you have to use the Finder for it. Moving it via command line doesn't help. – Amalia

I had this problem too + I couldn't add STS to the dock (icon would show up with a ? after restarting). I did the following which seems to have resolved the issue. 1.) Open a Terminal & cd to the location of your STS bundle. 2.) Run find . -exec xattr -d com.apple.quarantine {} \;. This goes through all the files in STS & removes the extended file attribute MacOS adds when you download an app from the Internet. It takes a while cause the utility is slow & there are a lot of files, but after it ran I can restart STS, it remembers my workspace location & the dock icon works. – Mancunian

So you should unpack it in one place and then put the .app in another location (with Finder). Is that the solution? – Vladikavkaz

Yes, that is the solution. Future versions of the Spring Tool Suite will ship as a dmg imagine (like many apps on macOS), which makes it easier, since you have to move the STS app out of the disc image anyway... :-) – Amalia

Answer 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

sudo xattr -r -d com.apple.quarantine /Applications/sts.app

where -r makes the command recursive for all app contents (macOS apps being folders) and -d deletes the particular attribute at the given path.

To verify a successful result simply run

sudo xattr /Applications/sts.app

The successful result you want is a new prompt line. If you get "quarantine" on there you were not successful.

Note that, I could only test this in macOS 10.12.6

Assuntaassur