[PATCH 2 of 2] Reorder rename operations to minimise risk of leaving repository in unknown state

[Adrian Buehlmann]

On 29.09.2009 11:28, Patrick Mézard wrote:
> Though I agree the antivirus behaviour is not really nice here, the 'rename files to atomically replace them' paradigm has much less weight on windows than on unix. We would just call os.rename() otherwise.
> 
> Looking at MoveFileEx() flags as Sune suggested may help with this, probably at the price or excluding non-(recent?)-NT versions or adding more complexity.

Not sure about the "less weight thing" (I fail to see how to achieve the
same without using that pattern) but MS created a specific example
in the msdn documentation for it (also using MoveFileEx with
MOVEFILE_REPLACE_EXISTING):

http://msdn.microsoft.com/en-us/library/aa363875(VS.85).aspx

MoveFileEx is available on Windows 2000 and newer, i.e. not
on WindowsNT.

Although I have some doubt whether MoveFileEx helps if scanners
just go locking files into memory as they please (Issue1820).

In my book, it is an error if scanners invalidate the Windows
API by blocking files at random times. I would expect from any
halfway decent scanner that it is completely transparent for
applications. I admit I don't know if such scanners exist
for Windows. But we seem to hear only of those that aren't,
obviously.

The two scanners we have seen causing problems are a real pain
though, since they seem to be fairly wide spread, probably
due to the fact that they are free of charge (a virus indeed).

People just don't understand what they do if they install them. The
end effect is what we have seen: people start blaming applications
(mercurial) for data loss.