Community
Participate
Working Groups
using 0323 12:08p integration build, happens on hpux only - unzip and start a new eclipse - at the "select a workspace" dialog just leave the default value as-is, check the "use this as default..." checkbox, and press OK - will soon get a dialog saying "workspace in use, choose a different one" - but this is obviously not the case Note that this hpux machine in the past had problems with the .lock file (was it an NFS problem?), so maybe this is similar? I'm launching eclipse with the following command line, which has worked fine in previous builds: ./eclipse -vm /opt/java1.4/jre/bin/java -vmargs -XdoCloseWithReadPending -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile
DataArea.createLockFile still access this system property but no one (in my workspace) calls this method. Who does the locking now? Moving to Equinox for comment.
The locking is done by the UI team. CCing Andrew for comments.
The UI calls Location.lock, but we actually implement it, right? I would suggest restoring the check for the -Dorg.eclipse.core.runtime.ignoreLockFile in the lock implementation (instead of the client).
UI sets the lock by calling either Location.setURL(URL value, boolean lock) (if the user selected a workspace in the dialog) or Location.lock() (if the workspace was already set, e.g., -data). It looks both of those methods wind up calling BasicLocation.lock(File) to create the actual lock file. It doesn't look like that method uses the DataArea method.
FYI... Here is a reference to the original bug about not being able to create the lock file on HP-UX: bug 44487. The system property check was added as a work-around for first a problem in the class libraries on hp-ux and then for behaviour on NFS mounted drives: bug 44735.
Pascal and I readded the workaround to BasicLocation to allow people to run when file locking does not work.
but this is just a temporary hack. The property has the wrong name. It hsould be something like osgi.locking=<value> where <value> is - none - java.io - java.nio If it is set to java.nio and nio is not available then use java.io.
Whatever definitive name we end up choosing, we should update bug 44735 so users are warned.
the workaround is in place. Dropping the severity and setting for M9 to implement the approach given in comment 7
The fix described in comment #7 has been fixed and released in HEAD.
Just to confirm... the default is java.nio, isn't?
Of course :-)
