[Python-Dev] windows file closing race condition?

[Tim Golden]

On 06/09/2013 12:50, Richard Oudkerk wrote:
> On 06/09/2013 11:23am, Tim Golden wrote:
>> On 06/09/2013 11:14, Antoine Pitrou wrote:
>>> Le Fri, 06 Sep 2013 08:58:06 +0100,
>>> Tim Golden <mail at timgolden.me.uk> a écrit :
>>>>
>>>> What should Python do?
>>>
>>> Maybe using FILE_SHARE_DELETE could help?
>>> http://bugs.python.org/issue15244
>>
>> I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
>> eg Virus Checkers) that typically causes the problem. IOW, the
>> sequence is:
>>
>> * [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
>> programs to delete the file even while this handle is still open
>>
>> * Python calls DeleteFile -- succeeds if the only open handles are
>> FILE_SHARE_DELETE; carries on
>>
>> * File has apparently disappeared but still has open handles
>>
>> * Any attempt to create a file of the same name or to delete a
>> containing directory fail because the file is still open, even though
>> it's successfully been deleted.
>>
>> * (Some time later) [Some Other Prog] closes its handle and the file is
>> now completely gone
>>
>>
>> Unless I'm missing something, there's nothing Python can do to help here
>> apart from the sort of delay-retry dance which test.support uses and
>> which I'm advocating against as a core feature.
> 
> Instead of deleting, the file could be moved to a temporary name in the
> root directory (or some other permanent directory on the same drive) and
> then deleted.  That would allow the directory to be closed even if a
> FILE_SHARE_DELETE handle is still open for the file.
> 

True, but then you're into determining a temporary name somewhere on the
same volume if possible and avoiding collisions etc. Again, I don't
think this is something we need to be doing by default in core Python.

TJG