Philip Martin wrote:
[snip]
>
> I think it's odd as well. The only thing I can suggest is that you
> tweak the numbers in the retry loop. I cannot imagine that it needs
> more that the 12 seconds it already gets, but perhaps it needs to
> sleep more that the current 128ms maximum?
>
The problem the retry loop attempts to solve is where *other* programs
(such as virus scanners) tag along after Subversion (or any program)
creates or changes files. They open up the file (essentially locking it
in Windows) and then do whatever they want with it -- usually scan it
for virii or index it for a search engine or whatever.
It's not a problem for other OS's (as I understand it, anyway) because
they allow in-use files to be deleted. Windows does not unless *all*
programs opening the file specify the FILE_SHARE_DELETE flag which is
not even supported on older versions of Windows and which I proved our
virus scanner did not use.
I find it hard to believe that any other program is keeping your files
open for so long, though it is possible...and as I said before I've
never seen a directory deletion fail unless an application or command
prompt or something had files open within it (which would cause the
delete of the file to fail before it even tried to delete the directory)
or else had the directory as it's process' current directory.
So perhaps you are running into a different problem...I'm clueless as to
what it could be though. Solo, can you use the FileMon utility at
sysinternals.com and try to get a log of the failure?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 24 04:35:13 2004