Buildengine fails to lock: Copy file area locked by another
Recently uplifted to RTC 2.0.0.1 from V1 and the buildengines are running but put out a weird error when processing:
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status ERROR: com.ibm.team.filesystem.client code=209 Copy file area locked by another process. Could not acquire lock on F:\IBM\awb_build\.jazz5\.jazzlock null
There isn't any other user and no files by the name listed on the error message. It seems the issue pops up during the fetch process.
Any help would be approciated
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status ERROR: com.ibm.team.filesystem.client code=209 Copy file area locked by another process. Could not acquire lock on F:\IBM\awb_build\.jazz5\.jazzlock null
There isn't any other user and no files by the name listed on the error message. It seems the issue pops up during the fetch process.
Any help would be approciated
5 answers
Recently uplifted to RTC 2.0.0.1 from V1 and the buildengines are running but put out a weird error when processing:
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status ERROR: com.ibm.team.filesystem.client code=209 Copy file area locked by another process. Could not acquire lock on F:\IBM\awb_build\.jazz5\.jazzlock null
There isn't any other user and no files by the name listed on the error message. It seems the issue pops up during the fetch process.
Any help would be approciated
Hi
I think I saw something similar on 2.0.0.0 - does your build try and clean out the build's local workspace first? Try stopping the build engine, deleting the contents of the directory by hand, then restart the build engine.
anthony
Recently uplifted to RTC 2.0.0.1 from V1 and the buildengines are running but put out a weird error when processing:
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status ERROR: com.ibm.team.filesystem.client code=209 Copy file area locked by another process. Could not acquire lock on F:\IBM\awb_build\.jazz5\.jazzlock null
There isn't any other user and no files by the name listed on the error message. It seems the issue pops up during the fetch process.
Any help would be approciated
Hi
I think I saw something similar on 2.0.0.0 - does your build try and clean out the build's local workspace first? Try stopping the build engine, deleting the contents of the directory by hand, then restart the build engine.
anthony
that was my first trick. I found that if I re-created the build definition, the issue went away. I'm not sure why but moving on is more important
Very strange. Deleting the directory should fix it up, and I wouldn't expect recreating the build def to have any effect, unless that also reset the "delete before load" setting to the default of on. But then that wouldn't have any extra effect if you'd already deleted the directory.
Do you have more than one JBE running on the same machine, with multiple build defs pointing to the same dir (or on separate machines if it's a shared dir)? They could be stomping on each other if so.
Do you have more than one JBE running on the same machine, with multiple build defs pointing to the same dir (or on separate machines if it's a shared dir)? They could be stomping on each other if so.
I also had this problem and stopping the build engine or cleaning up the workspace did not resolve it. Here's what caused my problem: The build engine and workspace are located on the same server. In my build definition, I was referencing the workspace using a UNC path, however my build ID did not have have network permissions to access the workspace. I changed the UNC path to the drive letter, and it works.