Resolved by:

e61e7b3e46d0 "util.rename: do not abort if os.unlink fails (issue1840)"

in crew stable

Most likely the virus scanner is opening the tempfile (created
by mercurial) without FILE_SHARE_DELETE flags, which causes the
later os.unlink in util.rename to abort.

If a process A opens a file without specifying FILE_SHARE_DELETE,
another processes B is denied deleting or renaming that file.
If the file is instead opened with FILE_SHARE_DELETE, delete
requests by other processes are just delayed until process A
closes the file.

It is quite common that applications create temporary files
which they delete later on.

However, a virus scanner should open files using FILE_SHARE_WRITE
and FILE_SHARE_DELETE access flags on Windows, so that
applications can continue to write and delete files without
aborting.

A patch for mercurial has been suggested on the -devel mailing
list, which ignores when os.unlink fails (instead of aborting).
Leaking a temporary file in that situation seems to be the lesser
evil, instead of trying to notify the user at the cost of leaving
more significant file inconsistencies (leaving an extra tempfile
behind does not render the repo corrupt. A subsequent clone --pull
on that repo will succeed to create a clean copy).

Nevertheless, I suggest to ask the makers of the virus scanner
why they open files without specifying the FILE_SHARE_DELETE flag
or possibly file a bug report on their product.

I’m sorry for wasting my time on this, please do pay attention to my other
patch for issue 1782.

Ok ok ok you made clear by now that the antivirus is really bad and that you
really don’t want this. Very selective quoting of information, but whatever :).

See also Matt's posting
http://selenic.com/pipermail/mercurial-devel/2009-September/015644.html

The interesting bits here are:

* Its another broken on-access virus scanner (AVG free anti-virus
software (http://free.avg.com/) that interferes with the disk access again.

* see also issue 1820

See also my analysis in comment #15:

http://bitbucket.org/tortoisehg/stable/issue/580/exception-after-using-revert-in-tortoisehg#comment-57703

Hi,

I got a traceback report after using the revert command in TortoiseHg 0.8.2,
and some pretty destructive behaviour.

This was originally filed as a TortoiseHg bug, which also has some
discussion on the topic:
http://bitbucket.org/tortoisehg/stable/issue/580/exception-after-using-revert-in-tortoisehg

The situation is as follows:

On a clone of http://hg.grauw.nl/grauw-lib/ revision bb67dc798a5c, I had
modified two files, test/selector.js and test/selector.html.

Through TortoiseHg, I did a revert on those two files, when the following
exception occurred:

** Please report this bug to tortoisehg-discuss@lists.sourceforge.net or
http://bitbucket.org/tortoisehg/stable/issues
** Mercurial version (1.3.1+1444a42f6052). TortoiseHg version (0.8.2)
** Command: --nofork revert --listfile
C:\DOCUME~1\laurens\LOCALS~1\Temp\THG73.tmp
** CWD: C:\Documents and Settings\laurens\Development\grauw-lib\test
** Extensions loaded: extdiff
Recoverable runtime error (stderr):
Traceback (most recent call last):
File "hggtk\status.pyo", line 1088, in revert_clicked
File "hggtk\status.pyo", line 1151, in hg_revert
File "hggtk\status.pyo", line 644, in reload_status
File "hggtk\status.pyo", line 575, in do_reload_status
File "mercurial\localrepo.pyo", line 1044, in status
File "mercurial\lock.pyo", line 119, in release
File "mercurial\dirstate.pyo", line 399, in write
File "mercurial\util.pyo", line 804, in rename
File "mercurial\util.pyo", line 447, in rename
WindowsError: [Error 5] Access is denied: 'C:\\Documents and
Settings\\laurens\\Development\\grauw-lib\\.hg\\dirstate-312af320'

What most likely seems to have happened is that TortoiseHg called
repo.status() to refresh the file view, when the AVG free anti-virus
software (http://free.avg.com/, running on Windows XP) that is installed on
my work computer interfered with the process causing this “Access is denied”.

After this exception, the dirstate got corrupted. When issueing a ‘hg
status’ command, it showed me a list of all files from the repository with a
‘?’ in front of them. To me this appeared as if the repository had been
corrupted, but I have been explained that was likely only the dirstate that
was corrupt. Nevertheless, the dirstate can contain some important
information that should stay intact.

Unfortunately I did not save a copy of the repository before attempting to
restore it (and eventually re-cloning it ‘just to be sure’), so to reproduce
this issue I guess you have to manually insert an exception in util.py.

Although I understand that this is in essence not Mercurial’s fault, I think
there could be better error handling on Mercurial’s part.

Suggested approach:

   1. User or TortoiseHg runs hg status
   2. Dirstate is rebuilt because it is out of date
   3. Error occurs renaming dirstate temp file, everything is rolled back
   4. hg status aborts with an error message 

   1. User or TortoiseHg runs hg status again
   2. Dirstate is rebuilt because it is out of date
   3. hg status succeeds 

This seems better than the 200ms sleep-approach suggested in issue 1820
(which is similar), and better than the exception-and-trash way things are
now :).

Additionally, in step 3 you could have an abort/retry/fail prompt.

Thanks,

~Laurens