Skip site navigation (1) Skip section navigation (2)

Re: rmtree() failure on Windows

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rmtree() failure on Windows
Date: 2004-10-25 21:01:39
Message-ID: 417D69B3.9060808@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-25 21:15:23
Subject: Re: rmtree() failure on Windows
Previous:From: Josh BerkusDate: 2004-10-25 20:54:53
Subject: Lamar stepping down

pgsql-patches by date

Next:From: Tom LaneDate: 2004-10-25 21:15:23
Subject: Re: rmtree() failure on Windows
Previous:From: Greg StarkDate: 2004-10-25 17:14:39
Subject: Re: [PATCHES] ARC Memory Usage analysis

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group