Locking is not possible in the directory C:\eclipse\configuration\org.eclipse.osgi

Question

I used to have Eclipse 3.5.2 working from my Limited User Account (i.e. not Administrator).

But when I upgraded to 3.6.2, Eclipse refuses to run in the Limited User Account (it only runs under administrator).

It issues the following error:

Locking is not possible in the directory C:\eclipse\configuration\org.eclipse.osgi. 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. C:\eclipse\configuration\org.eclipse.osgi.manager.fileTableLock (Access is denied)

Well, I checked the owner of that folder (Windows XP) and it is the Administrator, so of course access would be denied.

But... why didn't this happen in Eclipse 3.5.2?

I could probably workaround this by assigning ownership of the entire C:\eclipse\configuration\org.eclipse.osgi but without understanding why, I don't know whether I would need to do that for additional folders.

Another workaround is to do just as the error message suggests: Disable file locking passing -Dosgi.locking=none as a VM argument. But I don't what the tradeoff would be (locking is there for a reason, right? What is it?)

If I understand what the purpose of that locking is, I can wisely choose one of the 2 workarounds outlined above.

Answer 1

This has to do with running Eclipse in a multi-user environment, first read this Eclipse help section on multi user installations. When Eclipse was installed, it was done so as an admin account. This meant that the configuration folder was accessible and Eclipse thought this was a shared configuration or private install. Because of this Eclipse will first try to write data to the configuration catalog, but will fail for normal users.

What you want to do is to make Eclipse realize that you have a shared install installation and that all configuration data should be in the users home directory.

See this similar question and this IBM support answer for more information.

Answer 2

I had the same problem with the Juno version.

Several years ago I made a multiuser environment that worked perfectly, but the things changed with time. Now, my obvious solution, to change permissions, didn't work at all.

The issue is that the lock files have special permissions that the 777 won't change. Also, it is not the best solution just to provide the 777 to a directory inside any UNIX system (Linux, AIX, etc.); then, I worked around to another solution.

Inside the Eclipse directory you can find a eclipse.ini file. There you can put the vm arguments, although the one suggested by Eclipse won't work.

My environment started working with this one:

[email protected]/.eclipse

This way, each user inside the environment that run the Eclipse program, will create a different .eclipse directory inside the particular home, with full rights and zero problems.

I expect this to be useful for everyone "in the UNIX side".

Answer 3

Proper fix

Make sure you update the permissions of Eclipse and the workspace to whatever user Eclipse runs as. You can use ps -ef | grep -i eclipse while eclipse is running to find that user. Once you have the user, you can easily use chown -R user:group ~/Documents/workspace**

Hacky fix

1. Change permission of eclipse itself wherever you have it installed (in my case /opt/):

   sudo chmod -R 770 /opt/eclipse

2. Change permission of workspace wherever you have it located (in my case ~/Documents/):

   sudo chmod -R 770 ~/Documents/workspace

Hope this helps my fellow Linux users!

You can try this on windows with the proper syntax.

Thanks to Frederik for your help!

Answer 4

I wouldn't chmod to 777 to fix this problem. In my case the owner was root:root after a Rational Team Concert install for some RTC files and not my userid. Go to your user's home directory and ls -ltr to see what your userid and groupid are (on Ubuntu mine were both the same) and then execute the following on your eclipse subdirectory

sudo chown -R myuserid:groupid /opt/ibm/eclipse

Answer 5

I had this problem when trying to create a workspace in a mapped network drive.

One option is to start Eclipse from terminal with ./eclipse -vmargs -Dosgi.locking=none.

Another option is to add osgi.locking=none to the config.ini file in Eclilpse's configuration folder.

The second option is more convenient, but has the side effect of allowing any number of Eclipse instances running the same workspace.