Bug 84075

Summary: Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata
Product: [Retired] Red Hat Developer Suite Reporter: Phil Muldoon <pmuldoon>
Component: eclipseAssignee: eclipse-bugs
Status: CLOSED CURRENTRELEASE QA Contact: eclipse-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-09-04 15:50:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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 <aph>
To: Tom Tromey <tromey>
Cc: eclipse-list
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  <aph>

	* src/org/eclipse/core/launcher/Main.java (findBootSolib): New method.
	(getDevPath): Call findBootSolib.
	(processConfiguration): Call findBootSolib.