Corruption issue from filesystem exception.

Sune Foldager cryo at cyanite.org
Mon Feb 9 14:16:15 CST 2009


On 09/02/2009, at 18.02, Matt Mackall wrote:

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

Yes, I understand. It would be very nice, however, if it could try a  
bit harder like you suggested, sleeping for a while and spamming some  
warnings.

Also (but I didn't check into this), in case strip aborts completely  
on an error like that, it would be nice if it would continue with the  
rest of the files, to minimize the corruption caused, and possibly  
make manual (or tool-assisted) recovery easier (i.e. if the rename- 
from files were lying around, one could try to re-rename them or  
similar. Not sure how it works exactly, though). I will look into it a  
little.

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

Yes, I understand. But being able to retry, like I mentioned above,  
would still be better. Then no data would be "lost lost". Of course  
the corruption isn't bad, really, but still disconcerting :-p.

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

Indeed... so should I look into making a patch to sleep-retry renaming  
those files?

-- 
Sune Foldager



More information about the Mercurial-devel mailing list