Bugzilla – Full Text Bug Listing
| Summary: | Oxygen forgets its persistent state | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Olivier Croquette <ocroquette> |
| Component: | IDE | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bsd, Lars.Vogel, sravankumarl |
| Version: | 4.7 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Olivier Croquette
Related to 507328 and 461670 Seems related to bug 507328 and bug 461670 Can't reproduce on Linux. Brian, can you reproduce? Thank(In reply to Lars Vogel from comment #3) > Can't reproduce on Linux. Brian, can you reproduce? Thanks for the feedback Lars. In the meantime I found out this is clearly MacOS specific. See bug 507328 comment 15. Any MacOS user who currently uses the RC should be aware of this. *** This bug has been marked as a duplicate of bug 507328 *** You shouldn't encounter the problem if you download the DMG. (In reply to Brian de Alwis from comment #5) > You shouldn't encounter the problem if you download the DMG. Thanks Brian, I didn't try it, but I assume that will work. However, the MacOS app is, at some locations, available in other forms, like here as .tar.gz: http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M5-201701261030/ Any user who downloads this kind of file is likely to run into trouble. If possible, it would be better to provide DMG files everywhere, but on top of that, I think that detecting the problem at runtime is a good idea, if, for instance, Apple decides to change the rules when the translocation is activated, or if for instance a user creates its own ZIP or TGZ file to transfer the application. See bug 507328 comment 15. Sravan, should we stop distributing the .gz file? (In reply to Brian de Alwis from comment #5) > You shouldn't encounter the problem if you download the DMG. Hi Brian, I tried this again, I downloaded the following file: http://download.eclipse.org/eclipse/downloads/drops4/S-4.7RC4a-201706120950/download.php?dropFile=eclipse-SDK-4.7RC4a-macosx-cocoa-x86_64.dmg I mounted the DMG, then copied the .app file to my desktop, and started it. Obviously, the App Translocation was active, since the Target Platform (in the preferences) pointed to /private/var/folders/... Then I ran: $ if xattr -r Eclipse.app/ | grep com.apple.quarantine > /dev/null ; then echo "File is in quarantine" ; else echo "File is OK" ; fi File is in quarantine $ xattr -r -d com.apple.quarantine Eclipse.app/ $ if xattr -r Eclipse.app/ | grep com.apple.quarantine > /dev/null ; then echo "File is in quarantine" ; else echo "File is OK" ; fi File is OK Then I started Eclipse, and the Target Platform was at the expected location ($HOME/Desktop/...). So it looks like copying the .app from the DMG to the local file system is not enough to avoid the problem. Removing the "com.apple.quarantine" attribute manually is necessary. I am running macOS 10.12.3 (16D32) That's odd, as I tried the same thing and have no quarantine markers: $ codesign —verify --verbose /d1/e4/baselines/eclipse-SDK-4.7RC4a-macosx-cocoa-x86_64.dmg /d1/e4/baselines/eclipse-SDK-4.7RC4a-macosx-cocoa-x86_64.dmg: valid on disk /d1/e4/baselines/eclipse-SDK-4.7RC4a-macosx-cocoa-x86_64.dmg: satisfies its Designated Requirement [mount dmg on /Volumes/Eclipse] $ open /d1/e4/baselines/eclipse-SDK-4.7RC4a-macosx-cocoa-x86_64.dmg $ cd /Volumes/Eclipse/ $ xattr -r Eclipse.app and there are no attributes on any of the contents. When I copy Eclipse to my desktop and launch it, the Target Platform points to the /Users/bsd/Desktop/Eclipse.app/Contents/Eclipse/, as expected. This is on macOS 10.12.5. Dunno if there's some change between 10.12.3 that would affect this. (In reply to Brian de Alwis from comment #9) > $ cd /Volumes/Eclipse/ > $ xattr -r Eclipse.app > and there are no attributes on any of the contents. I don't have any attributes either on the app file in the mounted DMG, they appear only when I copy it. > This is on macOS 10.12.5. Dunno if there's some change between 10.12.3 that > would affect this. I found the difference. I use "Path Finder" as an more powerful alternative to the Finder (https://cocoatech.com/). If I copy the app with the Finder, it's fine, if I copy it with Path Finder, I have the problem. Maybe this could be fixed by the Path Finder developers, but there are clearly other scenarios where the attributes would be set, for instance if a user packages it to transfer it to himself or a colleague. The current solution is very fragile, I think that Eclipse should detect the situation and at least display a warning, or, at best, heal itself. Any idea on how/where to implement this at best? I could give it a try. Ah, nice find. Note that Eclipse is not the only application that suffers under this new security mechanism so the developers of Path Finder will need to fix this. I hope you'll report it ti them. My guess is that it might be best done in the launcher code (C/C++); the xattr(1) page lists a few library calls for listing attributes. But you might be able to get something up and going quickly in Java by using the org.eclipse.ui.startup extension point. At the very worst, you can shell out to xattr. The Eclipse launcher binary, if used, should be available from the System "eclipse.launcher" property: eclipse.launcher=/usr/local/installs/e4-dev/Eclipse.app/Contents/MacOS/eclipse I'm closing this as WORKSFORME since it does work with the OS-provided tools. |