Re: rmtree() failure on Windows

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Another data point - when rmdir() fails it fails quickly, but when 
>>unlink (i.e. our pg_unlink()) fails it takes a very long time (minutes) 
>>to fail. And the file is actually not there. So it looks like we loop 
>>over and over and keep getting EACCESS, and then get ENOENT, but the 
>>last one that failed with EACCESS actually succeeded. *sigh*
>>    
>>
>
>... or someone else deleted it in between our last EACCESS failure and
>the ENOENT try.  What someone else would that be?  More than likely,
>the same guy who was holding it open to cause the EACCESS failures.
>
>Perhaps there are paths in the code that don't go through win32_open?
>
>
>  
>

Well, on looking at the MS API at 
http://msdn.microsoft.com/library/en-us/vclib/html/vcrefRunTimeLibraryReference.asp 
I see that opendir() and friends aren't there, which means we might be 
at the mercy of what mingw does for us.

If I increase the sleep time before dropdb enormously (35 secs) the 
unlink errors seem to go away, and instead they become rmdir errors like 
the rest.

I am wondering if we need to look at using direct calls to the Windows 
API (findfirst() and friends).

cheers

andrew