WinIOError(13, 'Access is denied')

[Adrian Buehlmann]

On 30.06.2009 22:38, Matt Mackall wrote:
> On Tue, 2009-06-30 at 22:27 +0200, Adrian Buehlmann wrote:
>> On 30.06.2009 22:09, Matt Mackall wrote:
>>> On Tue, 2009-06-30 at 20:52 +0200, Adrian Buehlmann wrote:
>>>> 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).
>>> Oh, sure, the Windows kernel (of late) supports "deleting shared files"
>>> if you ask it nicely (though it's not really about sharing). The silly
>>> thing is that it's not the default.
>> CreateFile has no defaults :)
> 
> Of course it has defaults, and it's defaulting to stupid. The option
> should not be FILE_SHARE_DELETE (ie turn ON sane behavior) but
> FILE_DONT_SHARE_DELETE (turn OFF sane behavior). Then every program ever
> written for Win32 would do the right thing. By default.

You're right.

Maybe they had some stupid backwards compatibility issues.

Other than that I can't think of any reason why anyone would choose
such a default.