This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 84075 - Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata
Eclipse tries to write to /usr/lib/eclipse/workspace/.metadata
Status: CLOSED CURRENTRELEASE
Product: Red Hat Developer Suite
Classification: Retired
Component: eclipse (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: eclipse-bugs
eclipse-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-11 17:01 EST by Phil Muldoon
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-04 11:50:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Phil Muldoon 2003-02-11 17:01:38 EST
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-21 20:21:03 EDT
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 15:12:03 EDT
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 11:50:46 EDT
From: Andrew Haley <aph@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: eclipse-list@redhat.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  <aph@redhat.com>

	* 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.