Andrew Dunstan schrieb:
problem area found. see below.
Reini Urban wrote:
Andrew Dunstan schrieb:
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.
300 secs (!) fs timeout is really broken.
Looks more like a locking or network timeout issue.
What error codes does unlink(3) return?
success.
Oops! 5min timeout for success is certainly problematic.
Why don't you use DeletFileA() instead of unlink()?
Or even better, why don't you use this delete on close snippet instead:
[snip]
Before I tried anything like that I tried one more thing. I disabled the
background writer and the problem stopped. So now we know the "culprit".
Good! Relieve.
It should only happen a ERROR_SHARING_VIOLATION on NT systems with
such a long timeout. This is then a concurrency problem. win95 will
not return ERROR_SHARING_VIOLATION, only ERROR_ACCESS_DENIED
We don't support W95/W98/WME at all. The tests were done on XP-Pro.
Ah sorry. I forgot.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend