Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Thursday, September 08, 2005

Minor Eclipse Gripe

I'm a big fan of Eclipse; I think its full of great ideas, and is a big gift to the larger community. It gets the job done quite well. And it's free.

However, there are quite a few rough spots.

One thing I hit quite often is mysteriously locked files. I see this most often when updating or replacing my directories from SVN (and sometimes CVS). Often, an update will fail with some kind of locking error on the local file.

Sometimes, I have the file open in another window. I close the window and the process works. Less than ideal, but I can live with it.

Sometimes, I don't have the file open and I still get the error. My working theory is that Eclipse has it locked, perhaps due to indexing. Often I have to restart Eclipse to get the lock to clear!

Am I the only one who experiences this?

21 comments:

Anonymous said...

I don't seem to have problems with locked files very often; sometimes if I have it open in an external program (such as an external XML editor), Eclipse will complain that it is locked; but rarely do I have the inverse occur. Likewise, I don't seem to have a problem ever when committing to CVS, and I do it quite often.

Maybe the problem is centered around the SVN plug-in?

Anonymous said...

I too experience the same problem, but with CVS - it appears to happen after I update a file that is opened in the editor. Might be worth trying the stream build for 3.1.1 to see if this issue has been resolved.

Anonymous said...

I often experience that problem with svn. Too often. I have tried to shut down Eclipse and close all other programs and windows and it will still be locked. Usually I have to restart.

Mel said...

Hi HLS,

I just experienced this problem yesterday. I routinely modify files and perform Team->Replace With->Latest from HEAD when my local experiment is over. I didn't have the file open in an editor; I couldn't even delete it from within Eclipse. I had to close down Eclipse and delete it manually.

So you're not alone with your minor Eclipse gipe.

--Mel

Anonymous said...

Add me to the list of gripers. :-)

But again, I use CVS still. If I confine myself to only working on the project assets within Eclipse, I dont seem to have a problem. It's after I've been editing outside of Eclipse.

Another thing I would say, I dont think I've ever seen the problem under Mac OS X, so it might just been an issue affecting Windoze users.

Eugene Kuleshov said...

If you have XMLBuddy installed that is the guy!

Anonymous said...

in advance: this is no flame starter.

i've noticed locked files problems only on windows, but not linux. and tomcat has similar problems on windows too, thats why the "antjarlocking" and "antiresourcelocking" flags were added for running on windows.

the interesting question now is: has anyone noticed the locked files problems on non-windows systems?

fly

Anonymous said...

I had this problem and eventually tracked it down to my antivirus software - I told it to skip those directories and now I don't get the problem any more.

Anonymous said...

Using Eclipse in Linux for 2 years, from version 2.0 to 3.0.X and still no lock problems.

Anonymous said...

go to http://www.sysinternals.com and download their enhanced process explorer. This lets you (among other functions) search open file handles, so you can identify the process that locked your file. It even lets you close the handle right under the processes nose. It's incredibly useful.

Anonymous said...

sorry, that's http://sysinternals.org

Anonymous said...

Has been happening to me for a very long time, and I'm a cvs-only user. I was interested in eu's comment on XMLBuddy. I use XMLBuddy, and come to think about it, it mostly happens when I'm manipulating jsp files, which I have associated with XMLBuddy.

Anonymous said...

I noticed this many moons ago. I even added a bug report on it https://bugs.eclipse.org/bugs/show_bug.cgi?id=51057. Sadly, the Eclipse guys could never replicate it.

Some points:
1. This will not happen on Linux because files can be deleted from a directory, even if another process is using the file. When that process exits, the file is really deleted.

2. I second the use of the sysinternals tool. Sadly the Eclipse guys would not use it.

3. What happens is that for some reason FileStream objects are dereferenced before their file handle has been closed. When the garbage collector runs, it calls their finalize() method which really closes the file, and therefore it unlocks it. Thus: if you wait long enough, gc will close these files for you. Or you can exit the process and Windows will do the closing instead!

I guess we still need patience.

Anonymous said...

I used to suffer this problem a lot when editing files which are in the workspace outside of eclipse.

I turned off the auto-refresh (under preferences->general->workspace) and I can't remember the last time i had the problem. Of course, it does mean that you have to manually refresh to pick up changes made externally.

There's a handy little Windows Explorer extension called WhoLockMe (just google for it) that will tell you which process has locked a file...

Anonymous said...

It's been quite a while since I've had mysterious CVS problems such as this. I've never tried SVN.

Anonymous said...

There is also tool called Unlocker (http://ccollomb.free.fr/unlocker/), which can remove file locks. I've not tested this tool with Eclipse - I do not have the problem with locks (project in CVS, autorefresh disabled).

Anonymous said...

Refresh, man! I found that I was getting this on syncs with CVS when I had edited a file outside the workbench. Simply clicking on the file (or a folder higher up the folder hierarchy) and clicking refresh (or hitting F5) would turn the "dirty" flag on for that file and my issues would go away.

Of course, that may be a different problem than what you're experiencing.

Anjan said...

Hi Howard,

I use handle(another util from www.sysinternals.com) which lists all the handles to a process's resources and try to identify which process is responsible for the lock.

handle | grep -C 3 -i %*

As a previous user said, you can use procexp.exe to unlink(close) the handle. But usually a refresh of the project/workspace does the trick for me.

BR,
~A

Anonymous said...

I found that if I have a file that is being synced opened in another process (i.e. EditPro, Browser, OpenOffice), that the sync will fail --locked file. If I close the file in the other app and sync, all is well. Perhaps this is the cause?

Anonymous said...

I'm using eclipse3.1 + MyEclipse under Linux (not under Windows and never will happen) and I haven't experienced that problem

Anonymous said...

I have seen it happen to me almost all the time. I am not sure why and how. I do not have it open elsewhere. It is a complete mystery to me.