354

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.

Any tips?

Martin Geisler
  • 69,865
  • 23
  • 162
  • 224
jm.
  • 22,356
  • 20
  • 72
  • 91

11 Answers11

502

When "waiting for lock on repository", delete the repository file: .hg/wlock (or it may be in .hg/store/lock)

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

veeTrain
  • 2,873
  • 2
  • 22
  • 42
jm.
  • 22,356
  • 20
  • 72
  • 91
  • 103
    My problem had nothing to do with cloning or BSOD's but for me, I deleted the .hg/wlock file to clear up the lock. – frank hadder Feb 28 '10 at 07:59
  • 2
    Yeah, I think that is what you need to do if your system is stuck with: "hg commit waiting for lock on repository" – jm. Mar 01 '10 at 03:15
  • 32
    `hg recover` should be run after a broken locking situation. – James Broadhead Dec 08 '11 at 16:49
  • 9
    Many thanks - after removing .hg/wlock I had no idea what the issue was – Andrew Buss Oct 01 '12 at 01:35
  • 1
    I would like to mention that sometimes, ever after the `rm .hg/store/lock`, you will also need to run: `hg recover` which would do the associated rollback caused. :) – Fallenreaper May 28 '14 at 19:33
  • 34
    In my case (TortoiseHg V2.9.2 with Mercurial 2.7.2), the file name was "wlock" instead of "lock"; and it was placed in the ".hg" directory, not in ".hg/store". – Fernando Apr 24 '15 at 19:41
  • As a note I needed to use hg recover on the repository itself not from my local machine. Not necessarily obvious from the comments above. – lathomas64 Apr 28 '15 at 15:57
  • 2
    Repository get locked for a reason, another process is working on the repo. You should find that process and terminates it instead of blindly removing mercurial protection. Just dropping the file can lead to repository corruption. – Marmoute Jun 25 '15 at 00:48
  • didn't work for me as it always got locked again when I tried to push. As mine was a pretty new repo with a very short history I just deleted it and created a new one ... still curious to know what could have caused the lock in the first place. – retrovertigo Jul 01 '16 at 04:30
  • 7
    @Marmoute -- the repository gets locked whenever a change is going to be made. If something causes that process to fail -- ie, a bug in Mercurial, a machine going down, etc -- the lock files remain, not cleaned up. I believe the suggestions here to delete the lock files manually are to address those cases where the repository was somehow left in an "unclean" state. Calling it "blindly removing mercurial protection" is not a fair nor accurate characterization of what is going on in these cases. – JoGusto Aug 12 '16 at 15:14
  • 2
    I didn't have such a file in .hg/store but there was a file called wlock in .hg/ and deleting it solved the issue (without any apparent damage to the repo). – Mark Dec 22 '16 at 10:59
  • 1
    I removed the .hg/wlock file and it worked. The wlock file was empty, not sure if that is what caused it to get stuck. – Christo Nel Apr 18 '18 at 05:53
  • In my case (hg version 3.5.2 on Linux), .hg/wlock was a symlink pointing to nowhere: `.hg/wlock -> ip-xxx-xxx-xxx-xxx:xxxx` (i.e. ip and port) I was logged in remotely, had a file open in vim, and pulled. :D – George Marian Jun 28 '18 at 06:57
  • I wonder why this is still a thing after 11 years! When I interpreted that message I went into Process Explorer to see which process holds a 'file handle' on the directory, and found only hg (when it's waiting) otherwise nothing. So I was confused. Who still uses lock files that persist through reboot, when temp files can be made at the OS level (which self-delete) and locked for writing at the OS level? – Mark Jeronimus Aug 02 '19 at 09:21
348

When waiting for lock on working directory, delete .hg/wlock.

Karl Richter
  • 6,271
  • 17
  • 57
  • 120
Tiago Matos
  • 3,505
  • 1
  • 12
  • 2
  • 6
    This was the case for me. It was a symlink on 'nix to the current `server:pid`. Thanks a bunch. Then I had to run `$ hg recover` to clear out the existing journal (& commit message) which I `ctrl+c`'ed. Not sure, but you may be able to run `$ hg recover` without deleting the lockfile and it'll do it for you. Worth a shot I suppose. – sholsinger Apr 26 '11 at 00:43
  • 2
    Just a note for @sholsinger to say that running hg recover does not work unless you remove the lock first. I tried it. – Dan Jun 05 '13 at 18:33
  • 1
    Repository get locked for a reason, another process is working on the repo. You should find that process and terminates it instead of blindly removing mercurial protection. Just dropping the file can lead to repository corruption. – Marmoute Jun 25 '15 at 00:43
  • @Marmoute In my case I had to remove the lock, because no other process was working on the repo. But I agree, it's worth to look for another process first – Mi-La Apr 26 '17 at 17:54
  • I received this message suddenly when trying to pull, after pulling and pushing for a few days with no problems. After deleting the file the problem was solved. The file was of 0 KB which means I guess it was empty. Is it fine to simply delete the file? I guess it's usefull for protection. – Ben Carp Jan 15 '18 at 10:18
47

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.

Thomas Sharpless
  • 683
  • 6
  • 9
  • 23
    Protip: If `wlock` is the one locked up, use `hg debuglocks --force-wlock` – Brad Turek Sep 18 '17 at 16:32
  • 5
    I've used tortoise hg for 7+ years. I never saw the problem until about 3 months ago. I've seen it 3 time in the last 3 months. Some update must have exacerbated the problem. – d ei Feb 20 '18 at 00:49
  • Guys, both my locks show `free`, yet I get the `waiting for lock on working directory of \\uGames/MyGameRepo held by process '24012' on host MyHost`. After a long time of trying to push, `abort: working directory of \\uGames/MyGameRepo: timed out waiting for lock held by MyHost:24012`. I cannot push anything... How can I resolve this? – Reem Al-Assaf Jan 16 '21 at 17:13
20

Coworker had this exact problem today, after a BSoD while trying to push. He had to:

Then his repo worked again.

EDIT: As per @Marmoute's comment - when dealing with lock-related issues, using hg debuglock is a safer alternative to blindly deleting the .hg/store/lock file.

Community
  • 1
  • 1
Ian Kemp
  • 24,155
  • 16
  • 97
  • 121
  • 2
    1) There is absolutly no reason you should touch the phaseroots file, it is absolutly unrelated to locking. 2) blindling removing the wlock is a bad idea, there is likely another process using it. use hg debuglock to figure out what it happening and terminate the process holding the lock – Marmoute Jun 25 '15 at 00:45
  • 4
    1) Considering that removing it fixed the problem, I'd have to disagree. 2) Didn't know about hg debuglock at the time (cannot find any documentation on it either), and since the system had just come up from a reboot, there was obviously nothing locking the repository - hence deleting the lock file was appropriate. – Ian Kemp Jun 25 '15 at 07:30
12

I am very familiar with Mercurial's locking code (as of 1.9.1). The above advice is good, but I'd add that:

  1. I've seen this in the wild, but rarely, and only on Windows machines.
  2. 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.)

Brad O
  • 557
  • 5
  • 3
  • 2
    FWIW it just happened to me on Ubuntu. It was my first time using the repository in several weeks, so I don't remember what could have left it in that state. – Cosmologicon Oct 18 '14 at 14:29
7

I had the same problem on Win 7. The solution was to remove following files:

  1. .hg/store/phaseroots
  2. .hg/wlock

As for .hg/store/lock - there was no such file.

Kurt Van den Branden
  • 9,082
  • 8
  • 60
  • 72
Ivan Dulov
  • 87
  • 1
  • 2
  • Welcome to Stackoverflow. Try to add more content to the post – Nagama Inamdar Mar 12 '15 at 09:33
  • 5
    1) There is absolutly no reason you should touch the phaseroots file, it is absolutly unrelated to locking. 2) blindling removing the wlock is a bad idea, there is likely another process using it. use `hg debuglock` to figure out what it happening and terminate the process holding the lock. – Marmoute Jun 25 '15 at 00:41
6

I do not expect this to be a winning answer, but it is a fairly unusual situation. Mentioning in case someone other than me runs into it.

Today I got the "waiting for lock on repository" on an hg push command.

When I killed the hung hg command I could see no .hg/store/lock

When I looked for .hg/store/lock while the command was hung, it existed. But the lockfile was deleted when the hg command was killed.

When I went to the target of the push, and executed hg pull, no problem.

Eventually I realized that the process ID on the hg push was lock waiting message was changing each time. It turns out that the "hg push" was hanging waiting for a lock held by itself (or possibly a subprocess, I did not investigate further).

It turns out that the two workspaces, let's call them A and B, had .hg trees shared by symlink:

A/.hg --symlinked-to--> B/.hg

This is NOT a good thing to do with Mercurial. Mercurial does not understand the concept of two workspaces sharing the same repository. I do understand, however, how somebody coming to Mercurial from another VCS might want this (Perforce does, although not a DVCS; the Bazaar DVCS reportedly can do so). I am surprised that a symlinked REP-ROOT/.hg works at all, although it seems to except for this push.

Krazy Glew
  • 6,470
  • 1
  • 41
  • 56
  • Doesn’t hg track dirstate in `.hg/`? When you say that the repositories “work”, doesn’t running `hg up` in one put the dirstate out of sync in the other—or does mercurial do something special to support this? – binki Mar 06 '15 at 16:27
  • 1
    You can use the share extension (shiped with Core Mercurial) to have multiple working directory from a single repository. – Marmoute Jun 25 '15 at 00:47
6

I had the same problem. Got the following message when I tried to commit:

waiting for lock on working directory of <MyProject> held by '...'

hg debuglock showed this:

lock:  free
wlock:  (66722s)

So I did the following command, and that fixed the problem for me:

hg debuglocks -W

Using Win7 and TortoiseHg 4.8.7.

0xC0000022L
  • 18,189
  • 7
  • 69
  • 131
user10125940
  • 61
  • 1
  • 1
2

If the locked repo was the original, I can't imagine it was modifying it to clone it, so it was only preventing you from changing it in the middle and messing up the clone. It should be fine after removing the lock.

The new cloned copy (if it was a local clone) could be in any sort of malformed state, though, so you should throw it out and start it over. (If it was a remote clone, I would hope it failed and already threw out the incomplete copy.)

markpasc
  • 863
  • 8
  • 13
2

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.

JWWalker
  • 21,318
  • 5
  • 54
  • 72
  • 1
    *I found out that somehow the default path had gotten set to point to the same repository*. This. Thank, you - I went through loops to get rid of the problem and the `path` setting was the culprit one. – WoJ Feb 02 '16 at 08:40
1

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.

matt wilkie
  • 14,126
  • 21
  • 68
  • 99