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

I'd like to try to help track this down if I can, so I'd really appreciate
some info on the circumstances under which it is happening.

1) Does this repro with only one instance of stress.pl (as phillip suggested
trying).
2) This is happening on commit only also on updates?
3) Does it only affect entries files?
4) I thought I saw Brane say that the destination didn't exist. Why didn't
it, if it is just updating an entries file?

Can anyone give me some clearer details here?

On Wed, May 21, 2003 at 08:48:43AM -0600, D.J. Heap wrote:
> 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.
>
> DJ
>
> -----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
>
> http://www.cvsnt.org/pipermail/cvsnt/2003-February/005151.html
>
> "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 (...));
> }
> }
> #endif
>
> 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.
>
> www.mimesweeper.com
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~