|Summary:||Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata|
|Product:||[Retired] Red Hat Developer Suite||Reporter:||Phil Muldoon <pmuldoon>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||eclipse-bugs|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-09-04 15:50:46 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Phil Muldoon 2003-02-11 22:01:38 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I noticed this message has popped up again latley: The platform metadata area could not be written: /usr/lib/eclipse/runtime-workspace/.metadata I just rebuilt my system (disk was misbehaving) and I reinstalled 8.0 with the relevant Eclipse bits and pieces. It occured to me I had a really old snapshot: snapshot-20021121-eclipse-linux-gtk-2.0.1-11.i386.rpm so I installed: snapshot-20030211-eclipse-2.0.1-16.i386.rpm but the I still get the error. I can't remember if there was any action on the user side that was needed to get around it; I know Andrew patched it awhile ago. It seems to be wanting to write to /usr/lib again. full data: Exception in thread "main" java.lang.reflect.InvocationTargetException: org.eclipse.core.runtime.CoreException: The platform metadata area could not be written: /usr/lib/eclipse/runtime-workspace/.metadata. By default the platform writes its content under the current working directory when the platform is launched. Use the -data parameter to specify a different content area for the platform. at org.eclipse.core.internal.runtime.PlatformMetaArea.createLocation(PlatformMetaArea.java:72) at org.eclipse.core.internal.runtime.InternalPlatform.setupMetaArea(InternalPlatform.java:886) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:557) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.internal.boot.InternalBootLoader.startup(InternalBootLoader.java:909) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:768) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:432) at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:24 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create a plug-in example 2.Select Run->Run As->Runtime Workbench 3.See console window for error Actual Results: Console indicates Eclipse unable to run as it cannot write to /usr/lib/eclipse/runtime-workspace/.metadata Expected Results: Should have created another instance of the workbench with your plug-in running in memory Additional info:
Comment 1 Tom Tromey 2003-04-22 00:21:03 UTC
I tried this today and wasn't able to reproduce it. I'm closing the PR on the theory that it somehow got fixed. Can you reproduce this?
Comment 2 Phil Muldoon 2003-06-04 19:12:03 UTC
Reopened for tracking, and investigation See: http://post-office.corp.redhat.com/archives/eclipse-list/2003-June/msg00020.html
Comment 3 Andrew Haley 2003-09-04 15:50:46 UTC
From: Andrew Haley <email@example.com> To: Tom Tromey <firstname.lastname@example.org> Cc: email@example.com Subject: I fixed the mystery bug! Date: Wed, 3 Sep 2003 20:18:32 +0100 After a very long struiggle, I have discovered the problem. Okay, the bug was this. In launcher.Main, we have some code that converts from a .jar file to a .so, so that we run compiled code rather than starting the interpreter. We added this code to the point where we look for the .jar. The problem is that the boot file was being searched for in two separate places, dammit, rather than the one that we patched. So, sometimes we run the .so and sometimes we run the .jar, depending on which code path we follow. This triggers a gcj bug whereby there is a problem accessing static fields in a .jar from a .so. So, I made the code that looks for the solib into a private method and called it from *both* places. This fixes the problem. 2003-09-03 Andrew Haley <firstname.lastname@example.org> * src/org/eclipse/core/launcher/Main.java (findBootSolib): New method. (getDevPath): Call findBootSolib. (processConfiguration): Call findBootSolib.