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

Steve Borho steve at borho.org
Mon Sep 28 20:54:25 CDT 2009


On Mon, Sep 28, 2009 at 5:43 PM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
> Op 29-9-2009 12:24, Steve Borho schreef:
>>
>> A few of us discussed this issue on IRC today and came to the
>> conclusion this change would not have recovered the dirstate file
>> Mercurial was attempting to rename.  Until the AV tool releases the
>> renamed source file, any attempt to rename over the original filename
>> will fail.
>>
>
> How so? I don’t really follow why it wouldn’t…
>
> Let’s call the original file A and the new file B:
>
> 1. os.rename A to temp (succeeds)
> 2. AVG starts scanning and gets a lock on A

AVG scans the new file (temp).

> 3. os.rename B to dst (succeeds)

Still fails (see below).

> 4. os.unlink A (fails because of lock, but the new dirstate is in place)
>
>> Since there is very little interest in adding fall-back timers
>
> I don’t think doing stuff with timers is a good idea. I think the best
> approach would be to show an Abort/Retry/Fail prompt on file system errors,
> but in the absence of such, it should be good to try to minimise the risk of
> failure.
>
> And it’s not like I’m suggesting a huge change to accommodate the virus
> scanner :).

I'm hoping Sune will jump in here and explain this better.  But it's
my understanding that reordering the unlink() and rename() will not
resolve the problem like I expected.  The second rename will not
succeed even if the original (A) file was renamed, if the renamed
(temp) file is held open and locked.  Something about the way Windows
locks with directory entries instead of the physical files.

So it's not that we don't want to swap to lines to work around the
problem, it's that we're pretty sure it won't fix the problem.

--
Steve Borho



More information about the Mercurial-devel mailing list