I would agree that the file and directory are very, very likely to be
legitimately in use.
It is also possible (barely) on a heavily loaded system that a virus
scanner or something is hanging onto the file/directory for longer than
Subversion cares to keep retrying (around 10 seconds). I have never
seen it happen, though, even with extremely heavy testing and extremely
invasive AV software. And there's not much more Subversion can do about
that, anyway.
There are no places left where Subversion directly calls apr_dir_remove
(that I can find).
There are a few places left where Subversion directly calls
apr_file_remove, but as far as I can tell they are for temp files only
and do not cause any operation failures (they would leave the temp file
around, though):
libsvn_client\blame.c(333) -- temp file in pool cleanup
libsvn_client\export.c(452) -- only called on previous failures
libsvn_client\repos_diff.c(266) -- temp file in pool cleanup
libsvn_wc\update_editor.c(570) -- temp file and error is ignored
tests\libsvn_wc\translate-test.c(215) -- test, not subversion core code
These probably should be converted to svn_io_remove_file calls unless
there is some reason they deliberately do not use it? In any case, I do
not think any of these can be the real source of problems -- they just
might leave temp files behind.
DJ
Steve Dwire wrote:
> In these cases (especially the msvcp60.dll case) it may not be "ye olde
> race condition" bug of the past. These files may indeed be legitimately
> in use. I've had a couple forehead-slap moments where I've actually had
> a Windows Explorer window open snooping around in the .svn directory.
> That'll give an Access is denied error if SVN tries to delete the dir.
>
> For the DLL, use Process Explorer from www.sysinternals.com to see which
> process may still be using that DLL.
>
> S_E_D
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 10 19:51:15 2004