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-26 17:44:14
Message-ID: 417E8CEE.8030306@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>  
>
>>Here is some more info. Below is a trace from dropdb. There is a loop 
>>around the rmdir() calls which I have set to time out at 600 seconds. 
>>The call eventually succeeds after around 300 seconds (I've seen this 
>>several times). It looks like we are the victim of some caching - the 
>>directory still thinks it has some of the files it has told us we have 
>>deleted successfully.
>>    
>>
>
>If you rescan the directory after deleting the files, does it show
>as empty?
>  
>

No! That's how I got the list of "files it still thinks are there". 
Gross, eh?

>  
>
>>Bottom line, this is a real mess. Surely postgres is not the only 
>>application in the world that wants to be able to delete a directory 
>>tree reliably on Windows. What do other apps do?
>>    
>>
>
>I'm wondering if this is a side effect of the way win32_open does
>things.  It's hard to believe that rmdir is that bogus in general,
>but perhaps win32_open is causing us to exercise a corner case?
>
>
>  
>

I don't know. I tried to reproduce it in a simple case using 
fopen/fclose and wasn't able to.

cheers

andrew

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-26 17:57:05
Subject: Re: New compile warnings in CVS
Previous:From: Bruce MomjianDate: 2004-10-26 17:42:42
Subject: Re: New compile warnings in CVS

pgsql-patches by date

Next:From: Reini UrbanDate: 2004-10-26 22:07:47
Subject: Re: rmtree() failure on Windows
Previous:From: Tom LaneDate: 2004-10-26 17:27:24
Subject: Re: to_char/to_number loses sign

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