On 6/27/07, Bob Kerns <Bob.Kerns@positscience.com> wrote:
[snip]
> Second obvservation:
>
> The comment on WIN32_RETRY_LOOP doesn't really explain the situation
> properly.
> /*
> Windows is 'aided' by a number of types of applications that
> follow other applications around and open up files they have
> changed for various reasons (the most intrusive are virus
> scanners). So, if one of these other apps has glommed onto
> our file we may get an 'access denied' error.
>
> This retry loop does not completely solve the problem (who
> knows how long the other app is going to hold onto it for), but
> goes a long way towards minimizing it. It is not an infinite
> loop because there might really be an error.
> */
>
> This is only one of the scenarios that can cause it to fail. The main
> problem is that deleting is asynchronous. No virus scanners or other
> applications are necessary to provoke the problem.
True -- I'll clarify the comment. Erik Huelsmann found a couple of
places where we weren't using our wrapper functions, and I think I've
found another spot where the async nature of delete's could be causing
us grief despite the retry loop.
>
> Third observation:
>
> I think the number of iterations in WIN32_RETRY_LOOP should be
> substantially increased, probably by a factor of 10. (That shouldn't be
> necessary for handling the asynchronous deletes, but if it's virus
> scanner, etc, it should really give it more time before concluding it's
> not going to work).
Possibly...but it is already retrying for over 10 seconds and that has
alleviated all known occurences to my knowledge (I believe the issue
you are hitting is caused by another problem and a longer loop
wouldn't help). Making the user wait minutes in order to discover
what could be a real problem seems excessive to me.
>
> Final, MAIN observation:
>
> In this case, the problem (I believe) is in dir_make, which needs to use
> WIN32_RETRY_LOOP:
> status = apr_dir_make(path_apr, perm, pool);
> WIN32_RETRY_LOOP(status, apr_dir_make(path_apr, perm, pool);
>
> Probably also svn_io_make_dir_recursive:
> apr_err = apr_dir_make_recursive(path_apr, APR_OS_DEFAULT, pool);
> WIN32_RETRY_LOOP(apr_err, apr_dir_make_recursive(path_apr,
> APR_OS_DEFAULT, pool));
>
> What I believe is happening here, is that the delete of the tmp
> directory returns before the directory tmp has been removed, and the
> attempt to recreate it is failing when it happens before the actual
> removal.
Ah, yes I'll look at add the retry loop around that code.
> Sorry I can't actually make this change and verify it. If someone could
> make the change and ship me a svn.exe, I'd be happy to verify the fix.
> (And if you include the .pdb file, I can try to debug if it doesn't
> work).
>
> I don't think this is the same problem as I was seeing on svnadmin load,
> as the transaction directory names are incremented, so there shouldn't
> be a problem creating them. (Though perhaps the problem there is just
> not enough time for retry under heavy load?). I had to do another
> transfer, but since this was Windows to Windows (Server 2003) I just
> ROBOCOPY'd the repository instead of doing a dump/reload.
Right, I think it is a different issue as well -- our directory
deletion code was changed a while ago to 'rewind' and loop over any
remaining directory entries in order to work around a problem in OSX
and FreeBSD (I think). I think Window's async delete's are working
against us in that situation, but I haven't completely tested it yet.
Once I have finished testing and it works for me, I'll send you the
binaries zip to test out, if you would.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 27 23:45:10 2007