[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-22 20:41:58 CEST

I haven't tried repro-ing with one stress.pl yet -- I have had three or
four going when it happens...I've been trying (and so far wasting quite
a bit of time) to reproduce it in a test program. I'll start up a
single stress now and let it go.

I haven't been tracking the stress.pl failures really closely, since I
was hoping to get a test program going, but I will start doing that
since I'm losing hope on the test program, at least until I understand
better the sequence of operations.


-----Original Message-----
From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
Sent: Thursday, May 22, 2003 5:20 AM
To: D.J. Heap
Cc: 'Philip Martin'; dev@subversion.tigris.org
Subject: 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
some info on the circumstances under which it is happening.

1) Does this repro with only one instance of stress.pl (as phillip
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
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
> > me so far, though I'd guess that's just timing luck. It certainly
> > 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
> 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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 22 20:43:24 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.