[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: D.J. Heap <djheap_at_dhiprovo.com>
Date: 2003-05-21 16:48:43 CEST

The other odd thing is that normally a file still in use (like
CloseHandle hasn't been called) gives a different return code (File in
use), not Access Denied. I guess since CloseHandle has been called,
though, the file is in some oddball state or something. I'll look and
ask around on the MS dev forums.


-----Original Message-----
From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
Sent: Wednesday, May 21, 2003 8:18 AM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.

"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
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
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:50:09 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.