Community
Participate
Working Groups
There was a message to eclipse-dev this morning that shows how the workspace lock can be a major problem for users if it somehow fails to get cleaned up at shutdown: As I restarted my workstation today, I cannot open eclipse again. It comes all the time with the message "Workspace is in Use choose another one". AND I HAVE TO FINISH SOME WORK TODAY. I've read all the documents I could find to topic but nothing helps. And i cannot just replace my current eclipse because I'm using a lot of plugins which would take a lot of time to reinstall and configure all of them. Because the workspace lock can have such a costly effect on the user, we should provide some way for them to tell us that the we're wrong (in this guy's case, the workspace was *not* currently in use). I'd suggest adding a "Force" button to the dialog which would allow the user to launch despite the lock. The message would be changed to something like: "This workspace appears to already be in use. If you are certain that this workspace is not currently in use, click Force to proceed. Otherwise, please choose another workspace." Alternatively, we could just beef up the dialog to tell the user how to delete the lock manually.
I don't know the low levels with Samba shares but on Windows it doesn't matter if a ".lock" still exists from old sessions. If Eclipse can't write or delete this file a workspace is considered to be "in use". Thus, I think the user must hit a Samba specific locking problem.
Correct. Since 3.0, the simple existence of the .lock file does not mean anything (other than the workspace has been used before), because we don't delete it anymore. So far, we don't know of any cases where the workaround was to delete the .lock file. The problem of UI reporting always the same error message ("workspace is in use") regardless the workspaced was in use or the lock operation failed with an exception has been reported in bug 67053.
I just encountered this problem, and can confirm that: (a) It's very annoying. (b) Deleting the .lock file solved my problem. I'm running Eclipse 3.1 on a Linux/GTK box. I think the suggestion of adding a 'Force' button to the dialog is an excellent one, regardless of how the locking is handled.
i think a force button would be the best way to give the user the chance to open an apparent locked workspace. but by the way, can anybody explain the current locking mechanism in eclipse 3.1 in detail. in every locking bugzilla i can read that the .lock file is always present and would not be deleteted on eclipse exit. on which directory or file can i find out if a workspace is locked or not?
The workspace lock file is never deleted by Eclipse. The default locking mechanism uses java.nio.channels file locking support. When Eclipse exits (or crashes), the lock on the .lock file is released, but the file is not deleted. In general, there is no way of figuring out whether the workspace is locked just by looking at the file system contents. But on Windows, if you try to delete the .lock file and the file is open (we have to open the file to be able to lock it), the deletion fails. If you need more details, you can ask on the platform-core-dev mailing list. Re: comment 3 - the only I see this could happening is if after exiting/crashing Eclipse, the lock was not released somehow (it should be, as any files kept open by a process are automatically closed when the process ends - for whatever reason - thus releasing the lock). Deleting a file that is open by a process unlinks it from its directory, so a new file with the same would be created and successfully locked next time Eclipse starts.
"So far, we don't know of any cases where the workaround was to delete the .lock file." I just experienced a "workspace in use" error on startup. I had to terminate my project when a CDT build hung. Deleting the .lock file in the .metadata folder got it to start up properly.
So we need to understand your scenario better. What is your OS/file system? One thing to check next time it happens is whether there is an Eclipse process (i.e. a Java process running Eclipse) still running. That would explain the problem.
Also experienced the workspace lock when restarting Eclipse 3.1 after a close of the wb. The close was executed using win xp, toolbar, right clickling exit on the eclipse symbol. Found an eclipse process in the task manager list, size about 270 KB, and killed without further effects. Deleting the .lock file was not applicable due to fs lock. Also renaming that file didn't work (system response: .metadata\ cannot be renamed since it's in use...). What seems to work is using a 1to1 copy of the workspace (e.g. workspace.new). I'm using Eclipse out of the box plus the VSS plugin. And no, the old workspace isn't released after switching to the new one...
Killing the "eclipse.exe" process only kills the native launcher. Eclipse itself is a Java application and as such has "java.exe" or "javaw.exe" as the image name on the Windows task manager. That is the one that needs to finish properly for the lock to be released.
I am using windows eclipse3.2M4. Deleting .lock file was failed since the file is in use; killing javaw.exe was failed due to "Access is denied." What should I do?
I confirm this still hapening under 64 bit version of SUSE 10.1. After the crash with the out of memory error it is not possible to restart it: the "workspace in use" dialog appears instead. It helps just to restart the machine, but you cannot do this easily on a shared workstation. To remove the eclipse workspace lock, just delete the file .lock from the .metadata folder. This is a highly irritating bug with a large impact. Likely you assume that the operating system, java virtual machine, Eclipse itself and all other related things are absolutely reliable and it is much better to keep the user stupid. Likely this position is premature, and everibody must known how to force the thing working again after crash.
In all the discussion that's gone here, nobody has expounded upon the process to address the lock situation itself. I came to the conclusion that it must be a java issue, but don't know enough about java yet to debug it. My situation is that I locked up during a plugin install. Eclipse won't load, and I'm pretty sure that java is hosed to some extent. This is the best thread I've found so far - I'm just getting into Eclipse/java/PHP. I'd like to see some diagnostics and/or a force button. I'm running Eclipse 3.2.0 on Windows 2000 Server. I'm new to all this but, am an old-timey mainframe developer. This reminds me of the old "Probable user error" that used to be in all the error message descriptions. It would be helpful if someone would provide the unlock "key" to this situation in the form of some verbiage or a pointer to the source of that information.
I have just observed that under SuSe removing the lock file does not help if the Konqueror is configured just to move it to the trash folder. The file must be fully deleted, from the trash can as well. Likely the lock is kept if we just move the file. For me, Eclipse occasionally crashes with the out of memory error after a long work. Despite is shows the nice dialog, promising the clean termination, it seems that the actual termination is still not so clean.
Many of users I know complained about the "Workspace in use" message that they get after Eclipse crashed. I am aware of the fact that you can not tell if the workspace is in use or it is locked due to a crash, BUT I think you could change the message to something like: Workspace is unavailable due to one of: - it is used by another Eclipse - can not create a new workspace: check directory access rights - it is locked due to an Eclipse crash (read the log file in workspace/.metadata/.log and eventually remove workspace/.metadata/.lock file) This would be very usefull and give the users more hints on what is going on. It also does not imply more than changing message's text. Also Jared's ideea with the "Force" button seems to be ok. This issue is related to bug 119482.
I just had the same problem using Eclipse 3.3.1 on Fedora 6. Manually removing the lock file fixed the problem and I could use the workspace again. I couldn't try Eclipse 3.4 yet but as this bug is still open (and it's already 4 years old!) I'm assuming that this hasn't been fixed yet. What happened before was that because of another application my entire X session froze (while Eclipse was running) and I had to switch off my machine and reboot. When I launched Eclipse again I got the above message where Eclipse told me that the workspace is in use and I have to select another one (of course, the workspace was not in use anymore as this happened directly after rebooting the machine). In my case, the suggested "Force" button would have fixed the problem and saved me quite a bit of time. Personally, I would prefer though if this entire situation could be avoided somehow. I don't know the details about how the workspace metadata and lock file is managed but it seems that Eclipse assumes that it always gets the chance to terminate properly and that the disks are always available. In my case, those two things are not always given. While Eclipse itself is rather stable for me, it still can happen that X locks up and I just can't close Eclipse anymore or that the network goes away while Eclipse is running and the workspace is suddenly not available anymore (my workspace is not on a local drive). I have experienced before that these situations can mess up the workspace so that it gets unusable and requires some manual intervention (which you have to discover yourself by searching the web). Some things that come to mind which may improve the situation are: - Instead of just creating a lock file, Eclipse could also record the machine name and id of the Eclipse process. Then another Eclipse may be able to check whether that other Eclipse instance is still alive (if it's on the same machine). Even if it could not find out the status of that other Eclipse instance, it could still present that information to the user. - If Eclipse would notice during startup that a previous session didn't terminate properly, it could also know that the workspace that was open at that time was left in an invalid state and then fix that state. But as a quick workaround, the "Force" button would be fine by me. :) (this would also fix the case where Eclipse actually could terminate but the workspace disk was not available anymore and it couldn't modify the files in the .metadata directory. I had that case as well)
I have had the problem too. My platform is SUSE 10 Enterprise SP1 and my Eclipse is 3.4.1 with a plugin for ClearCase. Probably it was a malfunction of the ClearCase plugin that caused Eclipse to freeze. I used 'xkill' to terminate Eclipse, and then I faced the lockfile problem that has been described here. Rebooting was not an option for me. It took me some detective work to locate the logfile. I removed it and was able to restart Eclipse. Since I always start Eclipse from a wrapper script that chooses between several possible workspaces I was curious to see if I could add to lockfile handling to the wrapper. This turned out to be not so easy since the lockfile is always there, it is always empty, it has always the same permissions and it can always be written to. So, my question is: Is there any way that I could write a bash snippet that can determine the difference between a "locked" lockfile and a "released" lockfile? (the snippet may of course fire up a JVM if there is no other way) Until then (or until a "force" button is provided) my personal workaround will be to *always* let the wrapper write a description of how to remove the lockfile, should that be needed. Not so neat, but it will save me from the detective work next time.
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
This looks like a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=80734
*** This bug has been marked as a duplicate of bug 80734 ***
