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