CODEWITHSUNDEEP
mercurial
StayOnTarget
StayOnTarget

Reputation: 12988

How to recover repository when hg recover aborts?

Due to unknown reasons an HG command failed with the message:

abort: abandoned transaction found - run hg recover!

But when I tried to use recover to get rid of the abandoned transaction, I got a different error:

$ hg recover
rolling back interrupted transaction
attempted to truncate path/to/file to 12345 bytes, but it was already 456 bytes

and it aborted. The actual file was named like:

_some_filename.cs.i

which is an internal HG data file. So it seems like the HG data records for some_filename.cs are badly clobbered. And indeed running hg verify shows errors like this:

# hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 warning: revlog 'data/project/folder/some_filename.cs.i' not in fncache!
 13691: empty or missing project/folder/some_filename.cs
 project/folder/some_filename.cs@13691: manifest refers to unknown revision b269f6036278
 project/folder/some_filename.cs@13741: manifest refers to unknown revision 651b96abf6da
 ...

(goes on for a long time)

which corroborates that the file is damaged but doesn't do anything useful to fix it.

hg recover --help doesn't show anything else that I can do...

And aside from the apparent damage to this one file, no ordinary HG commands work at this point. All of them report the repository is damaged. How can I recover from this?

Upvotes: 2

Views: 1033

Answers (1)

StayOnTarget
StayOnTarget

Reputation: 12988

I concluded that this was just a situation that HG was not designed to deal with. For whatever reason HG's internal data file (the .i file) was destroyed.

It was helpful to review the HG source code which produced the key error:

if fp.tell() < o:
    raise error.Abort(
        _(
            b"attempted to truncate %s to %d bytes, but it was "
            b"already %d bytes\n"
        )
        % (f, o, fp.tell())
    )

(https://fossies.org/linux/mercurial/mercurial/transaction.py)

I'm not especially familiar with HG internals but this seemed to make it clear enough that HG was not able to handle the situation (understandably - arbitrary destruction of one of its data files leaves few options!).

The best workaround I could come up with was to manually copy the damaged .i file from another copy of the repository (on another PC). I didn't actually have local changes to that source file, so this seemed reasonable.

I copied the file (replacing the damaged original having made a backup first).

Then ran hg recover. This was now able to resolve the original "abandoned transaction" issue. Other HG commands work as well.

Worth noting that running hg verify still reports some errors (though many fewer). Perhaps the history of this single file is still not right; ultimately I think I will need to re-clone this repository but at least I can complete my immediate tasks without losing any work.

Upvotes: 2

Related Questions