The patch that the FAQ points to does 100 iterations with a one
millisecond sleep in each iteration. The sleep should be sufficient
to yield the CPU to the process holding the file open so that it will
finishing whatever it's doing and close the file.
I would rather see the loop bounded by time - say five seconds -
rather than a fixed number of iterations.
Note that a bound is needed since the file may never become available.
The simplest way for anti-virus software to sequester a file is to
not close the file.
The issue isn't atomicity but rather the Win32 API guarantee that a
file cannot be renamed or deleted while open.
One alternate solution would be to call the underlying NT API
directly, which can rename and delete open files. This does no good
for Win9x and would require use of many undocumented OS calls, but it
would allow the write-temp-rename-permanent method SVN uses.
A more realistic alternative, if rename retries do not work, is to
change write methodology to a rename of the permanent name to a .BAK
and then writing the new data directly to the permanent name.
Date: Sun, 26 Oct 2003 16:07:55 -0600
From: Luke Blanshard <luke@blanshard.us>
D.J. Heap wrote:
> ... With our AV software, the loop patch is the only way we can finish
> any non-trivial checkout or update -- it has even failed on incredibly
> trivial updates. I've recently upped the loop to 10,000 because on
> some machines under stress (a build is going and they do an update or
> checkout on another project) we still (rarely) experienced the problem
> on 100 and 1,000 count loops. Lovely. ...
Just out of curiosity, have you tried an exponential back-off, or are
you just blindly looping as fast as possible? Given that at least part
of the problem is contention with other processes, waiting before
retrying will probably give you better results.
It is of course a pity that Windows doesn't share Unix's approach to
atomicity in the filesystem. But it is still a fact. There is no way
to make this kind of algorithm perfect on Windows. In my experience,
some kind of retrying is an absolute necessity. As ugly as it of course is.
Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 27 18:27:25 2003