[issue2537] permission denied error when trying to acquire lock on Windows

Adrian Buehlmann bugs at mercurial.selenic.com
Sun Dec 5 04:09:16 CST 2010

New submission from Adrian Buehlmann <adrian at cadifra.com>:

(A finding based on theoretical pondering and some malicious manual poking at
lock files on windows)

Symptom (Mercurial 1.7.2):

  $ hg ci -m1
  abort: could not lock repository C:\Users\adi\hgrepos\tests\c: Permission denied

for a repository where the user *does* have write permissions.
How this can happen:

On Windows,

 (a) Mercurial process A acquires store lock by creating the file
 (b) Eager on-access AV scanner B notices a new file and opens it to scan it
 (c) "A" finishes its repo changes and os.unlink's the lock file
     while B is still holding it open, thus sending it into the dreaded
     "scheduled delete" state (see Issue2524 )
 (d) Mercurial process C tries to acquire the lock and fails with above
     error message

Note that nothing can be done with a filename in "scheduled delete". It can't
even be stat'ed or read.

What is bad about this?

Mercurial process C permanently gives up with a "Permission denied" even
though it *does* have write permissions on the repo.

What could be done better?

Maybe we could do one of:

(1) retry in lock() of lock.py if the error number is errno.EACCES (which
    is bad because EACCES is a so-called "permanent error")
(2) we could rename the lockfile to a random name before calling os.unlink()
    on it

I'm leaning towards option (2)

(from a discussion with mpm on IRC)

assignedto: abuehl
messages: 14589
nosy: abuehl, mpm
priority: bug
status: unread
title: permission denied error when trying to acquire lock on Windows
topic: windows

Mercurial issue tracker <bugs at mercurial.selenic.com>

More information about the Mercurial-devel mailing list