Ok, I've just done some reading on MS Essentials AV, and it looks like
what it does is this:
when a file is written, it hooks into the close, then reads the file
itself, and if its a virus, quarantines it.
So when bzr closes a large pack file, there will be a potentially
significant period while MS EAV is reading that file, and bzr is
simultaneously trying to rename it. And it does seem that this is a
slow thing - there are reports of users being able to *open* infected
zips before MS EAV scans them [which is, uhm, undesirable :)].
I repeat, could you *please* disable the real time scan facility in MS
EAV and try again. If it is an interaction with MS EAV we can look at
how to work around it (but really, its buggy, not even using the
filter drive approach other virus scanners have used for years to
avoid race conditions - like this one - permitting viruses to
execute).
Ok, I've just done some reading on MS Essentials AV, and it looks like
what it does is this:
when a file is written, it hooks into the close, then reads the file
itself, and if its a virus, quarantines it.
So when bzr closes a large pack file, there will be a potentially
significant period while MS EAV is reading that file, and bzr is
simultaneously trying to rename it. And it does seem that this is a
slow thing - there are reports of users being able to *open* infected
zips before MS EAV scans them [which is, uhm, undesirable :)].
I repeat, could you *please* disable the real time scan facility in MS
EAV and try again. If it is an interaction with MS EAV we can look at
how to work around it (but really, its buggy, not even using the
filter drive approach other virus scanners have used for years to
avoid race conditions - like this one - permitting viruses to
execute).
-Rob