Ken Yamada wrote:
Two issues I noticed with 3.3.1.
a) I have the following error if I try to assign workspace to NFS directory.
I have no problems in accessing any of NFS files with other than this eclipse-europa331, and Mike says that he does not have any problem in accessing NFS files with this.
b) The other issue I noticed is scim. The log says;
!ENTRY org.eclipse.ui.workbench 2 0 2007-10-12 16:12:26.507
!MESSAGE A handler conflict occurred. This may disable some commands.
!SUBENTRY 1 org.eclipse.ui.workbench 2 0 2007-10-12 16:12:26.507
: : :
This will happen with 3.3.0, and I'll dig into this weekend.
What could be the cause of the problems? Any suggestions?
<<< log file when I have a file access problem. >>>
# less workspace/.metadata/.log
!SESSION 2007-10-12 00:02:39.890 -----------------------------------------------
eclipse.buildId=M20070921-1145
java.version=1.6.0_01-p1
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=freebsd, ARCH=x86, WS=gtk, NL=ja_JP
Command-line arguments: -os freebsd -ws gtk -arch x86
!ENTRY org.eclipse.osgi 4 0 2007-10-12 00:02:40.197
!MESSAGE Error reading configuration: An error occurred while locking file
"/home/users/ken/.eclipse/514943809/configuration/org.eclipse.osgi/.manager/.fileTableLock":
"Operation not supported". A common reason is that the file system or Runtime Environment does not
support file locking for that location. Please choose a different location, or disable file locking passing
"-Dosgi.locking=none" as a VM argument.
!STACK 0
java.io.IOException: An error occurred while locking file
"/home/users/ken/.eclipse/514943809/configuration/org.eclipse.osgi/.manager/.fileTableLock":
"Operation not supported". A common reason is that the file system or Runtime Environment does not
support file locking for that location. Please choose a different location, or disable file locking passing
"-Dosgi.locking=none" as a VM argument.
at
org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio.lock(Locker_JavaNio.java:41)
at
org.eclipse.osgi.storagemanager.StorageManager.lock(StorageManager.ja...skipping...
at org.eclipse.osgi.framework.internal.core.OSGi.<init>(OSGi.java:31)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarte
r.java:283)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:172)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.Main.main(Main.java:1148)
Ken,
My apologies, I misunderstood your NFS issue yesterday. I don't have a
workspace created on NFS, but projects which are on NFS mounts. NFS
doesn't support locking, so what's in your logs is correct I'm afraid...
if Eclipse is trying to flock (or similar) files on NFS, it's going to
fail. If this wasn't the behavior in then 3.3.0 build, I wonder why
it's appeared with 3.3.1? I'm sure adding the flag mentioned in the log
will resolve it, but would still be interested to know why. ;-)
I'm not sure about the scim message you posted... I haven't built 3.3.1
here yet. (Just at the office.) I'll get to it tonight or tomorrow
with any luck!
Cheers,
Mike.
_______________________________________________
freebsd-eclipse@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-eclipse
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
