Community
Participate
Working Groups
Using Eclipse 4.2.2: eclipse-SDK-M20130116-1800-macosx-cocoa-x86_64.tar.gz eclipse-SDK-M20130109-1200-macosx-cocoa-x86_64.tar.gz eclipse-SDK-M20130104-1300-macosx-cocoa-x86_64.tar.gz (haven't checked earlier builds) On Mac OS X Mountain Lion, when I attempt to launch Eclipse 4.2.2, I get a dialog from the Gatekeeper, which says '“Eclipse” is damaged and can’t be opened. You should move it to the Trash.' I downloaded the .tar.gz, double-click in the Finder to extract, then navigate into the eclipse directory, and double-click on the Eclipse application to launch, and get the error. I also tried extracting from the command line using "tar xzf". Same result The Java I'm using: java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909) Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode) But I don't believe it gets far enough for the Java to matter. I don't see this problem with Eclipse 4.2.1; when I launch 4.2.1 for the first time, I get the expected message about Eclipse being from an unidentified developer
If I go to the Gatekeeper preference (System Preferences > Security & Privacy) and change to allow applications downloaded from anywhere, I can successfully launch Eclipse 4.2.2. According to Apple's documentation, changing the Gatekeeper preference should not allow a damaged application to launch: http://support.apple.com/kb/HT5290
In a terminal, can you navigate to the directory in which you extracted the (damaged) Eclipse.app and type: "xattr Eclipse.app/"? Curious to see if the attribute is something different than com.apple.quarantine. Could you make the download zip from your machine available? Also would it be possible to zip up the contents of your extracted Eclipse and make it available? What version of Mountain Lion are you running? (We are on 10.8.2). We haven't been able to reproduce this on any machine here; but searching around a bit it seems that this is a fairly common occurrence with other non-signed apps. The fix/workaround suggestions seems to be the same: turn off Gatekeeper, launch once, turn it back on or sign the app.
$ xattr Eclipse.app/ com.apple.quarantine I'll upload the .tar.gz I'm using, and also a zip of the extracted contents, and I'll send you a link to where you can download them. I'm on Mountain Lion 10.8.2
I did a diff of the files inside Eclipse.app between 4.2.1 and 4.2.2 $ diff eclipse4.2.1/Eclipse.app/Contents/Info.plist eclipse4.2.2/Eclipse.app/Contents/Info.plist 25a26,27 > <key>NSHighResolutionCapable</key> > <true/> When I delete that stanza from the 4.2.2's Info.plist, Gatekeeper no longer sees the app as damaged. When I add it back, Gatekeeper again objects. If I add that stanza to 4.2.1's Info.plist, Gatekeeper now thinks that 4.2.1 is damaged.
(In reply to comment #4) > I did a diff of the files inside Eclipse.app between 4.2.1 and 4.2.2 > > $ diff eclipse4.2.1/Eclipse.app/Contents/Info.plist > eclipse4.2.2/Eclipse.app/Contents/Info.plist > 25a26,27 > > <key>NSHighResolutionCapable</key> > > <true/> > > > When I delete that stanza from the 4.2.2's Info.plist, Gatekeeper no longer > sees the app as damaged. When I add it back, Gatekeeper again objects. > > If I add that stanza to 4.2.1's Info.plist, Gatekeeper now thinks that 4.2.1 > is damaged. I'd be the last to know, and not sure where to find official docs, but googling around, I see many blogs that say to use <key>NSHighResolutionCapable</key> <true/> But a few that say to use <key>NSHighResolutionCapable</key> <string>True</string> Such as ... http://help.infinitekind.com/discussions/problems/4227-macbook-pro-retina-display-support Just wondering ....
Played around some more, its not specifically the NSHighResolutionCapable setting thats the problem, its any difference from the Info.plist that came with 4.2.1. Removing the NSHighResolutionCapable stanza, then changing the contents of the string associated with the CFBundleGetInfoString key also causes the problem, for example. I've seen references on the 'net about the Mac aggressively caching the information in the Info.plist file, and I'm wondering if that's related. I do have another Eclipse 4.2.1 already on the system from before.
So ... I'm wondering what to do with this bug? Is a fix from us required? Sounds like "signing the app" will "fix" the general problem, but the specific you are seeing may be "not eclipse"?
I'll assume there's nothing for us to do here, but please re-open if you learn more. (We hope be the Kepler release, the "CBI build" will handle signing the executable).
In the interim you can tweak the "xattr" on the app using the command: xattr -d com.apple.quarantine Eclipse.app/
You should know this is still a problem with the Eclipse 4.3 "Kepler" release that came out yesterday. I think you should not resolve this as a "NOT_ECLIPSE" problem. Even though we are all developers and can google for this bug and find the command that overrides the Gatekeeper logic, I think it is worth pointing out that no other Mac application has this problem, even the ones that are not properly signed do not show up as damaged.
Is there any fix for this issue? It's causing problems with Subversion accessing the keychain: http://subclipse.tigris.org/issues/show_bug.cgi?id=1454
(In reply to comment #11) > Is there any fix for this issue? It's causing problems with Subversion > accessing the keychain: > > http://subclipse.tigris.org/issues/show_bug.cgi?id=1454 You mean fixes besides the workarounds mentioned in previous comments? You might read http://support.apple.com/kb/HT5290 if interested.
(In reply to comment #12) > You mean fixes besides the workarounds mentioned in previous comments? Yeah...I'm able to work around this for myself, by manually signing the app. But I assume most users won't know to do that. Isn't this a bug in Kepler? I've never seen this problem in any other release of Eclipse.
When I try to open Eclipse.app (from eclipse-standard-kepler-R-macosx-cocoa-x86_64.tar.gz) it by plain double click in Finder the following is shown in the system log. Note that "code or signature have been modified" sounds quite different from (and scarier than) the usual downloaded-app-is-not-trusted-... messages that can be solved by right-clicking and opening it once from the pop-up menu. 7/4/13 8:17:22.156 PM taskgated[1263]: failed to get signing info for pid=3835 (cannot make code: invalid signature (code or signature have been modified)) 7/4/13 8:17:22.220 PM CoreServicesUIAgent[3837]: Error SecAssessmentCreate: The operation couldn’t be completed. (OSStatus error -67061.) 7/4/13 8:17:24.106 PM com.apple.launchd.peruser.501[219]: ([0x0-0x62062].org.eclipse.eclipse[3835]) Exited: Killed: 9 This is on OS X 10.8.4. I have not seen this on any other app, regardless of whether they are unsigned or not. I downloaded eclipse-SDK-4.2.2-macosx-cocoa-x86_64.tar.gz today too and it does not have the problem (it brings up the expected dialog that warns about it being downloaded from the internet and then allows me to run it). This gives no output in the system log.
Fixed Try to expand the .tar.gz using command line or another tool rather than the built in app. I had the same problem. I figured out that for some reason "Archive utility.app" in OSX 10.8 is damaging the files when extracting them from the tar.gz I tried out with other app (StuffIt expander) and now I can run eclipse 4.3.
(In reply to Sergio Pino from comment #15) > Fixed Try to expand the .tar.gz using command line or another tool rather > than the built in app. > > > I had the same problem. I figured out that for some reason "Archive > utility.app" in OSX 10.8 is damaging the files when extracting them from the > tar.gz > > I tried out with other app (StuffIt expander) and now I can run eclipse 4.3. Just to be sure, did you try the same version of 4.3 with both utilities? I ask since we recently ?M1? (and Kepler SR1 to be) started 'signing' the app, and I've often wondered if this would cause the problem to "disappear" (for those that were having it).
(In reply to David Williams from comment #16) > Just to be sure, did you try the same version of 4.3 with both utilities? I > ask since we recently ?M1? (and Kepler SR1 to be) started 'signing' the app, > and I've often wondered if this would cause the problem to "disappear" (for > those that were having it). Yes, I tried to expand the same file "eclipse-standard-kepler-R-macosx-cocoa-x86_64.tar.tar.gz" with both utilities. Results: - When running the eclipse.app extracted with the built in app, I got the "Eclipse.app” is damaged and can’t be opened. You should move it to the Trash." - Whit Stuffit expander the eclipse.app runs as expected. Best,
