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

[Laurens Holst]

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
3. os.rename B to dst (succeeds)
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 :).

> into Mercurial to work around unfriendly AV checkers, you're only recourse
> is to figure out how to disable AVG free inside your repository or
> switch to another anti-virus tool.  I don't recommend using Mercurial
> with AVG free, as the next time it breaks a rename it could be a file
> that is not as recoverable as dirstate.
>    

A file system developer can not get away with saying that “you should 
not use our file system with faulty drives” (or memory, or drivers, or 
chips). File systems tout features like CRC checks and journaling and 
even parity information that improve robustness. And if things still go 
horribly wrong, the user gets an Abort/Retry/Fail prompt.

Don’t you think Mercurial should aim for similar robustness, within 
limits of reason?

> I've added a note to the front page of TortoiseHg's wiki to this effect.
>    

Yes, I saw that.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3274 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090929/13c1d990/attachment.bin