Corruption issue from filesystem exception.

[Matt Mackall]

On Mon, 2009-02-09 at 16:54 +0100, Sune Foldager wrote:
> 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?

This is why strip and everything that uses it is banished to
extension-land. It's inherently dangerous.

> 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?

There's no such thing as a Mercurial-style rollback for strip because
it's deleting data. Rollback simply truncates back to a known-good
point. Any real undo-like functionality for strip would be vulnerable to
the very same unexpected things that would cause strip to break in the
first place.

> 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 :-).

Modifying history is simply not something that makes sense as part of
the Mercurial core. It'd make more sense as part of a pull --repair.

But I don't think automated repair is something we should be spending
our time on. It's much better to focus on automated not-breaking.

-- 
http://selenic.com : development and support for Mercurial and Linux