[PATCH 1 of 1 STABLE] readlock: close lock file as early as possible

Adrian Buehlmann adrian at cadifra.com
Sun Dec 5 04:20:37 CST 2010


On 2010-12-05 00:04, Matt Mackall wrote:
> On Fri, 2010-12-03 at 01:33 +0100, Adrian Buehlmann wrote:
>> # HG changeset patch
>> # User Adrian Buehlmann <adrian at cadifra.com>
>> # Date 1291335788 -3600
>> # Branch stable
>> # Node ID a8d607c0565008848e207a54dc08ca3edff005fe
>> # Parent  5e51254ad4d4c80669f462e310b2677f2b3c54a7
>> readlock: close lock file as early as possible
>>
>> Avoiding Windows' "scheduled delete" state on the lock file, which
>> happens if the lock file is unlinked while it is open.
>>
>> Scheduled delete state prevents creating the lock file, which
>> is bad.
> 
> What happens? Don't we simply try again in a loop?

(as discussed on IRC with mpm)

For the other list readers:

I've filed http://mercurial.selenic.com/bts/issue2537
("permission denied error when trying to acquire lock on Windows")

My patch is pointless for CPython, since the file is closed immediately,
because the reference count of the file object goes to zero right when
the function returns, which in turn causes the file to be closed
immediately.


More information about the Mercurial-devel mailing list