[issue2537] permission denied error when trying to acquire lock on Windows
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:
(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
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()
I'm leaning towards option (2)
(from a discussion with mpm on IRC)
nosy: abuehl, mpm
title: permission denied error when trying to acquire lock on Windows
Mercurial issue tracker <bugs at mercurial.selenic.com>
More information about the Mercurial-devel