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

[Steve Borho]

On Sat, Oct 3, 2009 at 6:35 AM, Sune Foldager <cryo at cyanite.org> wrote:

> Laurens Holst wrote:
> > I think the core problem here is that in Windows, there is simply not
> > a concept of an atomic rename to an existing file.
>
> Indeed. It works like this: You can never rename a file into an existing
> file in any way. Also, you CAN delete an open file (if opened with
> correct share modes), but it will not disappear from the directory list
> until it is closed. Finally, you CAN rename an open file (if opened with
> correct share modes), and the rename WILL take place immediately,
> fortunately. This is why the code looks as it does right now.
>
>
Based on this, I think the patch would help.  I'll take leaked temp files
over missing repository files any day of the week.  Doing the unlink last
will still throw an exception, which is the right thing to do.  Mercurial
should throw a great big fit when it is interfered with like this (so people
switch A/V tools), but reordering the calls makes us more resistant to data
loss.

--
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20091003/a442007b/attachment.htm