mercurial - wlock - waiting for lock on working directory of held by hg
Mercurial stuck “waiting for lock” (8)
Got a bluescreen in windows while cloning a mercurial repository.
After reboot, I now get this message for almost all hg commands:
c:\src\>hg commit waiting for lock on repository c:\src\McVrsServer held by '\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' interrupted!
Google is no help.
Coworker had this exact problem today, after a BSoD while trying to push. He had to:
delete the file
.hg/store/lock(as per the accepted answer )
delete the file
.hg/store/phaseroots(as per this TortoiseHG bug report )
Then his repo worked again.
As per @Marmoute's comment - when dealing with lock-related issues, using
is a safer alternative to blindly deleting the
I am very familiar with Mercurial's locking code (as of 1.9.1). The above advice is good, but I'd add that:
- I've seen this in the wild, but rarely, and only on Windows machines.
- Deleting lock files is the easiest fix, BUT you have to make sure nothing else is accessing the repository. (If the lock is a string of zeros, this is almost certainly true).
(For the curious: I haven't yet been able to catch the cause of this problem, but suspect it's either an older version of Mercurial accessing the repository or a problem in Python's socket.gethostname() call on certain versions of Windows.)
I encountered this problem on Mac OS X 10.7.5 and Mercurial 2.6.2 when trying to push. After upgrading to Mercurial 3.2.1, I got "no changes found" instead of "waiting for lock on repository". I found out that somehow the default path had gotten set to point to the same repository, so it's not too surprising that Mercurial would get confused.
I had the same problem on Win 7. The solution was to remove following files:
As for .hg/store/lock - there was no such file.
I had this problem with no detectable lock files. I found the solution here: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError
Here is a transcript from Tortoise Hg Workbench console
% hg debuglocks lock: user None, process 7168, host HPv32 (114213199s) wlock: free [command returned code 1 Sat Jan 07 18:00:18 2017] % hg debuglocks --force-lock [command completed successfully Sat Jan 07 18:03:15 2017] cmdserver: Process crashed PaniniDev% hg debuglocks % hg debuglocks lock: free wlock: free [command completed successfully Sat Jan 07 18:03:30 2017]
After this the aborted pull ran sucessfully.
The lock had been set more than 2 years ago, by a process on a machine that is no longer on the LAN. Shame on the hg developers for a) not documenting locks adequately; b) not timestamping them for automatic removal when they get stale.
If it only happens on mapped drives it might be bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . Using UNC path instead of drive letter seems to sidestep the issue.
waiting for lock on working directory
When "waiting for lock on repository", delete the repository file:
(or it may be in
When deleting the lock file, you must make sure nothing else is accessing the repository. (If the lock is a string of zeros or blank, this is almost certainly true).