Bug 84075 - Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata
Summary: Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Developer Suite
Classification: Retired
Component: eclipse
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: eclipse-bugs
QA Contact: eclipse-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-11 22:01 UTC by Phil Muldoon
Modified: 2007-04-18 16:51 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-09-04 15:50:46 UTC
Embargoed:


Attachments (Terms of Use)

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.




Note You need to log in before you can comment on or make changes to this bug.