WinIOError(13, 'Access is denied')

[Adrian Buehlmann]

On 30.06.2009 17:40, Matt Mackall wrote:
> On Wed, 2009-07-01 at 01:34 +1000, Sean wrote:
>>>> adding test.php
>>>> Exception mercurial.util_win32.WinIOError: WinIOError(13, 'Access is denied') in
>>>>   <bound method lock.__del__ of <mercurial.lock.lock object at 0x006E3710>> ignored
>>> Can you manually delete the wlock file here without error? Whenever
>>> we've seen this error, it's been because something else (usually a virus
>>> scanner) decided to open the file right after we created it and when we
>>> went to delete it milliseconds later, it still had it open. We've fixed
>>> that issue with a bit of filename juggling in more recent code.
>> Yes, I can manually delete the wlock files.
>>
>> Perhaps this process list (from NAS) may help to id the culprit (i don't think it is a virus scanner)
> 
> Not likely. Linux and other Unix-like kernels don't have this silly
> behavior. If one user deletes a file while another is reading it, both
> operations succeed. This is either caused by a weird protocol issue (SMB
> is quite obsolete) or by something running on your desktop.

Interestingly, this time it seems the silly behavior is not due to
Windows "kernel" itself but due to the error of lots of programs
on Windows failing to call WinAPI CreateFile with FILE_SHARE_DELETE on
parameter dwShareMode -- which enables other processes to delete or
rename a file while it is open (note that CreateFile is used to
open a file on Windows).

Sadly, this seems to include for example implementations of functions like
fopen from the C runtime by Microsoft themselves (I just checked the CRT
sources as provided by Microsoft in Visual C++ 2005).

>> Will this "lock.LockError on line 1066 of localrepo.py to error.LockError" likely be fixed in the 
>> next release of HG ?
> 
> Yes, it was fixed months ago.