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

Laurens Holst laurens.nospam at grauw.nl
Sat Oct 3 06:23:47 CDT 2009


Op 3-10-2009 11:51, Adrian Buehlmann schreef:
> Note that the damage reported in issue 1840 is most likely caused by
> a specific virus scanner hard-locking files at random times.
>    

Not really random, probably after it received a notification from the 
file system hook it tied in to that a file was created/renamed. But 
definitely unexpected.

> If I try to take on Laurens' (=Grauw) hat, assuming I had used such a
> horrible scanner together with Mercurial, I would probably even go as
> far as saying that if my file access is broken that much, then
> I would probably try not to abort the program if the "only" problem is
> that deleting a temporary file fails.
>    

Makes sense. Sorry if it wasn’t immediately obvious that I == Grauw, by 
the way.

> Maybe doing something inelegant as (comments omitted, pasting full
> modified function):
>    

Well, inelegant because it doesn’t look so pretty, but I think generally 
it is probably good practice to handle exceptions…

> But at least the repository would still be usable in that
> specific failure case. I could then ask on IRC or the ml what that
> fatal error means, then learn that it is most likely caused by my
> broken virus scanner, then shut down the scanner, make a clone of
> the repo and continue with the clean clone (without the scanner or
> a hopefully better scanner).
>    

I’m guessing that would also be a good approach. The current error also 
prompts me to take action, but it says to report it to the bug tracking 
system. It might be better to show a more descriptive, and less severe 
error message. And it alleviates Sune’s concerns with changing the order.

> Of course, it still doesn't fix the basic problem that the scanner
> is incompatible for usage with mercurial (and probably many other
> software as well).
>    

I don’t know, I think in practice there won’t be many software trying to 
do these kind of operations (deleting a file right after renaming it), 
so they get away with it. Also, even then it seems to be a race 
condition that they usually probably win.

~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/20091003/7458fe6b/attachment.bin 


More information about the Mercurial-devel mailing list