[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn.collab.net is now running Subversion 0.23.

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-05-21 16:18:06 CEST

"D.J. Heap" <dj@shadyvale.net> writes:

> Simply retrying the MoveFileEx seems to work fine most of the
> time...once in a while it requires multiple retries to get through,
> though. A Sleep(1) in front of the retry has been 100% successful for
> me so far, though I'd guess that's just timing luck. It certainly has
> the feel of a race.

I am a little surprised, I would expect a race to be much more widely
seen, but I did find this


"Basically, when you call CloseHandle, it doesn't actually close the
 handle, it just asks to OS nicely to do it when it gets around to it.
 This can randomly cause the MoveFileEx that happens about 100th of a
 second later to fail with a locked file."

I don't know enough about Windows to be able to say if the explanation
is correct, but the symptoms sound the same.

Now when Subversion calls svn_io_file_rename it always expects the
rename to succeed, perhaps we should use that knowledge and change
svn_io_file_rename to something like

    status = apr_file_rename (...);
#ifdef SVN_WIN32
    if (status is "Access is denied")
        status = apr_file_rename (...); // immediate retry
        if (status is "Access is denied")
              apr_sleep (...); // or some sort of Windows flush or magic
              SVN_ERR (apr_file_rename (...));

We can't really do that in APR since it is, in general, perfectly
acceptable for apr_file_rename to fail with a permissions problem.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 16:18:59 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.