Corruption issue from filesystem exception.

[Sune Foldager]

Matt wrote:

> Perhaps you can manufacture a simple test without Mercurial involved to
> see if a virus scanner is getting in the way. Something like:
>
> while 1:
>  create file a
>  create file b
>  delete file a
>  move b a
>  delete file a

Yes, I will do that when I get a change to get my hands on the particular
machine. I do believe it could well be the problem, as we have had problems
with our virus scanner before.

> Yes, we do use renaming, but we've got some Windows-awareness in those
> areas. But another application opening that file (like a virus scanner)
> will make us trip up. We could probably add a short retry loop (and some
> cursing) to deal with that.

Yes, that would be nice :-). However, isn't it also a problem that strip
corrupts data in case it can't write to a file?
I suppose the file that couldn't be renamed would still be left in the file
system, so a manual recovery might be attempted,
but is there any possibility we could make strip more atomic so it would
either complete or rollback? I am not asking for it
to be isolated with respect to other hg-operations against the repository,
but ending up with a corrupted repo is somewhat
problematic :-/.

As an alternative, maybe repo verify or a new command could repair the
problems found? In case of strip, it seems mostly to
be revision numbers that are 1-n off, with all other revision numbers
matched correctly. Alternatively, it could look for the
files that couldn't be renamed and try again, or something. I'd be happy to
help with any testing or developing in this area,
of course :-).

-- 
Sune Foldager