Restoring files from a corrupt bundle

[Erik Muttersbach]

Hi,

I have a bundle file from a strip command. If I want to restore it I get
the following error:

hg unbundle .hg/strip-backup/68a8f24f62d0-backup.hg
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: received file revlog group is empty

I also tried a pull without success:

hg pull .hg/strip-backup/68a8f24f62d0-backup.hg
pulling from .hg/strip-backup/68a8f24f62d0-backup.hg
searching for changes
adding changesets
transaction abort!
rollback completed
abort: data/sc2-local.tar.i@2cad29d699f8: no node!

I am executing these operations in the original repository, without any
change after the strip.

Whats wrong here? i have no backup of the strip and I hope I am not
screwed now ...

Erik

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Mon, 2010-11-29 at 18:31 +0100, Erik Muttersbach wrote:
> Hi,
>
> I have a bundle file from a strip command. If I want to restore it I get
> the following error:
>
> hg unbundle .hg/strip-backup/68a8f24f62d0-backup.hg
> adding changesets
> adding manifests
> adding file changes
> transaction abort!
> rollback completed
> abort: received file revlog group is empty

What happens if you comment out this abort at localrepo.py:~1751? (hint:
replace it with 'pass')

Does the result pass verify?

> I also tried a pull without success:
>
> hg pull .hg/strip-backup/68a8f24f62d0-backup.hg
> pulling from .hg/strip-backup/68a8f24f62d0-backup.hg
> searching for changes
> adding changesets
> transaction abort!
> rollback completed
> abort: data/sc2-local.tar.i@2cad29d699f8: no node!

Interesting. You may be able to recover pieces with:

hg -R <bundle file> log / cat / etc.

--
Mathematics is the supreme nostalgia of our time.

[Erik Muttersbach]

---------- Forwarded message ----------
From: Erik Muttersbach <er...@muttersbach.net>
Date: Mon, Nov 29, 2010 at 7:25 PM
Subject: Re: Restoring files from a corrupt bundle
To: Matt Mackall <m...@selenic.com>

If I use the cat command on changed files I get the following:

hg -R ../../sc2/68a8f24f62d0-backup.hg cat -r 986d0d73e1b9 sc2-master/build.xml
abort: data/sc2-master/build.xml.i@8bebfb85e319: no match found!

I replaced the "raise ..." statement with a pass and now the program
runs for quite a while. I'll let it do an report.

One problem might be: I have commited two files which are some GB big.
This commit is included in the patch - can this be a problem?

Erik

[Erik Muttersbach]

Update: After removing the raise statement and enabling the --debug
flag, I see weird stuff on the terminal output:

Ƈ� �Ƈ� 3Ƈ� �Ƈ�Ƈ� Ƈ� �Ƈ� rƇ� 4Ƈ� ?Ƈ� ;Ƈ� 0Ƈ�Ƈ� Ƈ� �Ƈ� �Ƈ� >Ƈ� 2Ƈ� �Ƈ� �Ƈ�Ƈ� AƇ� �Ƈ� �Ƈ� �Ƈ� %Ƈ� �Ƈ�
�������������UH���H�� ƇI H��� ����ƀ� H�� H9�u�Ƈ� Ƈ� �Ƈ� �Ƈ�Ƈ�Ƈ� �Ƈ� �Ƈ� Ƈ� @Ƈ� Ƈ� Ƈ� [ Ƈ\ Ƈ] Ƈ��
Ƈ� �Ƈ� 3Ƈ� �Ƈ�Ƈ� Ƈ� �Ƈ� �Ƈ� $Ƈ� �Ƈ� �Ƈ� �Ƈ�Ƈ� Ƈ� �Ƈ� �Ƈ� �Ƈ� �Ƈ� �Ƈ� 0Ƈ�Ƈ� Ƈ� �Ƈ� �Ƈ� �Ƈ� �Ƈ� 'Ƈ

Is this supposed to be correct?

Erik

[Erik Muttersbach]

Well, another update:

I put a break statement instead of the raise/pass statement. Now the
unbundle operation finishes without errors and I can see the commits
from the bundle in the log. The problem now is that if I want to
merge, I still get the errors:

data/sc2-local.tar.i@2cad29d699f8: no match found

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 19:37 +0100, Erik Muttersbach wrote:
> Well, another update:
>
> I put a break statement instead of the raise/pass statement. Now the
> unbundle operation finishes without errors and I can see the commits
> from the bundle in the log.

Did you run verify? A break is not correct here.

--
Mathematics is the supreme nostalgia of our time.

[Erik Muttersbach]

The verify tells me something like this:

...
313: empty or missing
sc2-master/src/com/sc2/master/web/controller/service/RPackageServiceControla
sc2-master/src/com/sc2/master/web/controller/service/RPackageServiceController.java@313:
4cf6c96dd
sc2-master/src/com/sc2/master/web/controller/service/SessionServiceController.java@313:
5acf64283d
sc2-master/src/com/sc2/master/web/controller/service/WorkspaceServiceController.java@313:
8617945d
sc2-master/src/com/sc2/utils/AWSUtils.java@315: 82e065188139 in
manifests not found
data/sc2-master/src/com/sc2/utils/ExtensionFilenameFilter.java.i@313:
missing revlog!
313: empty or missing sc2-master/src/com/sc2/utils/ExtensionFilenameFilter.java
sc2-master/src/com/sc2/utils/ExtensionFilenameFilter.java@313:
10327f7bc328 in manifests not found
data/sc2-master/src/com/sc2/utils/Monitor.java.i@314: missing revlog!
314: empty or missing sc2-master/src/com/sc2/utils/Monitor.java
sc2-master/src/com/sc2/utils/Monitor.java@314: 3952227551d1 in
manifests not found
data/sc2-master/src/com/sc2/utils/SpringFactory.java.i@313: missing revlog!
313: empty or missing sc2-master/src/com/sc2/utils/SpringFactory.java
sc2-master/src/com/sc2/utils/SpringFactory.java@313: 2194dfdc3643 in
manifests not found
sc2-master/src/com/sc2/web/WorkspaceCopier.java@313: a8af12e96f38 in
manifests not found
...
10644 files, 317 changesets, 11856 total revisions
208 integrity errors encountered!
(first damaged changeset appears to be 313)

The changeset 313 is exactly the first changeset of the bundle.

One file (a tar archive) was about 2GB the other was about 8GB. I cant
remember the exact sizes.

Erik

On Mon, Nov 29, 2010 at 7:51 PM, Matt Mackall <m...@selenic.com> wrote:

> On Mon, 2010-11-29 at 19:25 +0100, Erik Muttersbach wrote:
>> If I use the cat command on changed files I get the following:
>>
>> hg -R ../../sc2/68a8f24f62d0-backup.hg cat -r 986d0d73e1b9 sc2-master/build.xml
>> abort: data/sc2-master/build.xml.i@8bebfb85e319: no match found!
>>
>> I replaced the "raise ..." statement with a pass and now the program
>> runs for quite a while. I'll let it do an report.
>>
>> One problem might be: I have commited two files which are some GB big.
>

> How big are they precisely?

[Matt Mackall]

Odd, it shouldn't be possible to actually commit files that large.
Mercurial currently has a 31-bit (2GiB) limit on the size of individual
file revisions (though file history for a singe file can run to 48 bits
or 281TB). How big is your bundle file?

We haven't had much pressure to move that boundary (it's easy to move it
from 2G to 4G), because people generally run into other problems (disk
space, bandwidth, memory) before they hit it.

[Erik Muttersbach]

The bundle size is 185.1mb. If there is a file size limit, why was I able to commmit these files?

How is the bundle file encoded/compressed? A sophisticating solution for me would be to get the changes/diffs from the bundle, I can merge them on my own, but for this I need to know how I can make the contents of the bundle file readable.

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 20:33 +0100, Erik Muttersbach wrote:
> The bundle size is 185.1mb. If there is a file size limit, why was I able to commmit these files?

Good question. I suspect they didn't make it into the bundle though -
it's unlikely to find 10GB of data hiding in a 185MB archive.

> How is the bundle file encoded/compressed? A sophisticating solution
> for me would be to get the changes/diffs from the bundle, I can merge
> them on my own, but for this I need to know how I can make the
> contents of the bundle file readable.

http://mercurial.selenic.com/wiki/BundleFormat

[Erik Muttersbach]

Thanks for the link. I uncompressed the bundle and have a more or less
readable file.

Some parts seem to me to be binary:

H<8b>E<90>E1íL^A
I<8d><96>^H+^@^@H<89>×H<89><95>xÿÿÿè^@^@^@^@I<8b><8e>è)^@^@H<8b><95>xÿÿÿH<83>éhë^Oë^B<90><90>ÇA`^@^@^@^@H<8d>O<98>H<8b>yhL<8d>AhM9Ç^O^X^OuåH<89>ÆH<89>×M<89>¾è)^@^@M<89>¾ð)^@^@è^@^@^@^@L<89>÷ètìÿÿH<89>ßè^@^@^@^@IcÅE<85>íI^ODÄH<83>Äh[A\A]A^A_ÉÃë^A<90>A<8b>¶^@*^@^@º^A^@^@^@L<89>÷èüêÿÿ<85>À^O<84>«^B^@^@I<8d><86>Ø)^@^@I;<86>Ø)^@^@AÇ<86>^D*^@^@^A^@^@^@AÇ<86>^H*^@^@^B^@^@^@^O<85>Òþÿÿë(ë^F<90><90><90><90><90><90>H<89>ßè^@^@^@^@H<83>Äh1À[A\A]A^A_ÉÃë^E<90><90><90><90><90>I<8d><96>è)^@^@I;<96>è)^@^@tDI<89><86>Ø)^@^@I<89><86>à)^@^@1ÀI<89><96>è)^@^@I<89><96>ð)^@^@f<90>AÇ<84>^F8^Z^@^@^@^@^@^@AÇ<84>^Fè^Y^@^@^@^@^@^@H<83>è<80>H=^@^P^@^@uÜL<89>÷è<84>ëÿÿéGþÿÿë^E<90><90><90><90><90>AöE9^Hë^A<90>^O<85>^Z^B^@^@A^O·¾<9a>*^@^@iÿè^C^@^@è^@^@^@^@M;¾è)^@^@^O<84>â^@^@^@H<85>À^O<88>Ö^A^@^@A<8b><96>
*^@^@öÂ^BujH<85>Àt
<83>â^D^O<84>^LþÿÿH<89>ßë^B<90><90>è^@^@^@^@HÇÀûÿÿÿé­þÿÿf<83>=^@^@^@^@^@t:I<8b><86>
^Y^@^@L<8b> Ø^@^@^@M<85>äu^GL<8b>
<98>^@^@^@H<8d>¸<88>^@^@^@è^@^@^@^@L<89>âH<89>ÆHÇÇ^@^@^@^@1Àè^@^@^@^@H<89>ßè^@^@^@^@HÇÀíÿÿÿéUþÿÿf<83>=^@^@^@^@^@t<86>I<8b><86>
^Y^@^@L<8b> Ø^@^@^@M<85>äu^GL<8b>
<98>^@^@^@H<8d>¸<88>^@^@^@è^@^@^@^@L<89>âH<89>ÆHÇÇ^@^@^@^@1Àè^@^@^@^@éGÿÿÿë^D<90><90><90><90>Aö<86>
*^@^@^F^O<85>^PÿÿÿL<8d>m HÇE
^@^@^@^@HÇE°^@^@^@^@eH<8b>^T%^@^@^@^@I<8d>M^XH<89>U¨H<89>U<80>H<89>M¸H<89>MÀI<8d><8e>(+^@^@H<89>M<88>H<8b>}<88>H<89><85>xÿÿÿº^A^@^@^@L<89>îè^@^@^@^@M;¾è)^@^@H<8b><85>xÿÿÿu,Aö<86>
*^@^@^Fu"H<8b>M<80>H<8b>Q^HH<8b>R^P<83>â^D^O<85>×^@^@^@H<89>Çè^@^@^@^@H<85>Àu¬H<8b>}<88>H<89><85>xÿÿÿL<89>îè^@^@^@^@H<8b><85>xÿÿÿéaþÿÿf<83>=^@^@^@^@^B^O<87>©^@^@^@H<89>ßè^@^@^@^@HÇÀðÿÿÿé'ýÿÿf<83>=^@^@^@^@^@uCH<89>ßè^@^@^@^@HÇÀôÿÿÿé
ýÿÿH<89><85>xÿÿÿH<89>ßè^@^@^@^@H<8b><85>xÿÿÿéîüÿÿH<89>ßè^@^@^@^@HÇÀõÿÿÿéÚüÿÿI<8b><86>
^Y^@^@L<8b> Ø^@^@^@M<85>äu^GL<8b>
<98>^@^@^@H<8d>¸<88>^@^@^@è^@^@^@^@L<89>âH<89>ÆHÇÇ^@^@^@^@1Àè^@^@^@^@ë<81>HÇÀ^@þÿÿé*ÿÿÿI<8b><86>
^Y^@^@L<8b> Ø^@^@^@M<85>äu^GL<8b>
<98>^@^@^@H<8d>¸<88>^@^@^@è^@^@^@^@A¹^V^C^@^@H<89>ÆIÇÀ^@^@^@^@HÇÁ^@^@^@^@L<89>âHÇÇ^@^@^@^@1Àè^@^@^@^@é^Dÿÿÿ<90>UH<89>åAWAVAUATSH<83>ì^Xè^@^@^@^@L<8b>§
^Y^@^@1öH<89>ûL<89>çè^@^@^@^@¾^G^@^@^@H<89>Çè^@^@^@^@H<8b>@^P¾Ð<80>^@^@D^O·h^DF<8d><í^@^@^@^@E)ïE<89>þL<89>÷è^@^@^@^@H<85>ÀH<89><83>¸^Y^@^@^O<84>í^A^@^@¾Ð<80>^@^@L<89>÷è^@^@^@^@H<85>ÀH<89><83>À^Y^@^@^O<84>Ð^A^@^@H<8d>C^PI<89>ÞH<89>EȾÐ^@^@^@¿^G^@^@^@è^@^@^@^@H<85>ÀI<89><86>¨^Y^@^@^O<84>»^A^@^@L<89>`HH<89><98>°^@^@^@1ÉA<8b>^T$Ç@d^B^@^@^@Ç<80>¤^@^@^@^G^@^@^@HÇ<80>¸^@^@^@^@^@^@^@Áâ^H<81>Ê<80><80>^@^@<89>PXI<8b><96>¸^Y^@^@D<89>¸<84>^@^@^@Ç<80>¨^@^@^@^A^@^@^@H<89>Ph1Òë^E<90><90><90><90><90><89><8c>^PÀ^@^@^@D<89>¬^PÄ^@^@^@H<83>Â^PD^AéH<83>úpuäI<83>Æ^HL;uÈ^O<85>Yÿÿÿ1öL<89>ç²^Gè^@^@^@^@<85>ÀA<89>Ät[f<83>=^@^@^@^@^@^O<85>g^A^@^@H<8b>»¨^Y^@^@H<85>ÿt^Vè^@^@^@^@H<8b>»°^Y^@^@H<85>ÿt^Eè^@^@^@^@H<8b>»¸^Y^@^@H<85>ÿtZè^@^@^@^@H<8b>»À^Y^@^@H<85>ÿtIè^@^@^@^@ëBë^E<90><90><90><90><90>H<8b>»¨^Y^@^@HÇ<83>Ð^Y^@^@^@^@^@^@¾Ð^@^@^@è^@^@^@^@<85>ÀA<89>Äu6H<8b>»°^Y^@^@¾Ð^@^@^@è^@^@^@^@<85>ÀA<89>Äu^RH<83>Ä^XD<89>à[A\A]A^A_ÉÃH<8b>»¨^Y^@^@è^@^@^@^@f<83>=^@^@^@^@^@^O<84>LÿÿÿH<8b><83>
^Y^@^@L<8b>¨Ø^@^@^@M<85>íu^GL<8b>¨<98>^@^@^@H<8d>¸<88>^@^@^@è^@^@^@^@D<89>áH<89>ÆL<89>êHÇÇ^@^@^@^@1Àè^@^@^@^@é

Some other parts can be read. However, I could not find code pieces of
every change that I made and that should be included in this commit.

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 21:17 +0100, Erik Muttersbach wrote:
> Thanks for the link. I uncompressed the bundle and have a more or less
> readable file.

How big is the result? The individual deltas in the bundle won't be
compressed, so if it's not 10G, it won't contain your large files.

> Some parts seem to me to be binary:
>
> H<8b>E<90>E1íL^A
> I<8d><96>^H+^@^@H<89>×H<89><95>xÿÿÿè^@^@^@^@I<8b><8e>è)^@^@H<8b><95>xÿÿÿH<83>éhë^Oë^B<90><90>ÇA`^@^@^@^@H<8d>O<98>H<8b>yhL<8d>AhM9Ç^O^X^OuåH<89>ÆH<89>×M<89>¾è)^@^@M<89>¾ð)^@^@è^@^@^@^@L<89>÷ètìÿÿH<89>ßè^@^@^@^@IcÅE<85>íI^ODÄH<83>Äh[A\A]A^A_ÉÃë^A<90>A<8b>¶^@*^@^@º^A^@^@^@L<89>÷èüêÿÿ<85>À^O<84>«^B^@^@I<8d><86>Ø)^@^@I;<86>Ø)^@^@AÇ<86>^D*^@^@^A^@^@^@AÇ<86>^H*^@^@^B^@^@^@^O<85>Òþÿÿë(ë^F<90><90><90><90><90><90>H<89>ßè^@^@^@^@H<83>Äh1À[A\A]A^A_ÉÃë^E<90><90><90><90><90>I<8d><96>è)^@^@I;<96>è)^@^@tDI<89><86>Ø)^@^@I<89><86>à)^@^@1ÀI<89><96>è)^@^@I<89><96>ð)^@^@f<90>AÇ<84>^F8^Z^@^@^@^@^@^@AÇ<84>^Fè^Y^@^@^@^@^@^@H<83>è<80>H=^@^P^@^@uÜL<89>÷è<84>ëÿÿéGþÿÿë^E<90><90><90><90><90>AöE9^Hë^A<90>^O<85>^Z^B^@^@A^O·¾<9a>*^@^@iÿè^C^@^@è^@^@^@^@M;¾è)^@^@^O<84>â^@^@^@H<85>À^O<88>Ö^A^@^@A<8b><96>
> *^@^@öÂ^BujH<85>Àt

Those look like our binary delta chunks.

Much to my surprise, it is possible to commit files > 2G and even verify
and clone the result locally. And you can even commit changes to such
files, but you won't be able to check out those changes as the delta
applying code will get confused. I'll be adding a check to make sure we
refuse to commit such large files in the future.

[Erik Muttersbach]

Is it possible to decode the binary data of the chunks?

Erik

[Erik Muttersbach]

The size of the uncompressed file is actually only about 750mb, so I think my large files may not be included there, However, I can see in the very beginning of the uncompressed bundle file a line that contains the path to one of these big files.

Is there a manual way to decode the binary chunks?

Erik

[Erik Muttersbach]

I just found out that the size of the file I commted was 3050086400 Bytes, so about 2.8GB. You wrote that you use 31bit, so this probably caused an overflow?

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 22:07 +0100, Erik Muttersbach wrote:
> I just found out that the size of the file I commted was 3050086400
> Bytes, so about 2.8GB. You wrote that you use 31bit, so this probably
> caused an overflow?

It'll cause an overflow in a few places:

a) when writing the first revision to the revlog, we'll store an
uncompressed size modulo 2G, but we'll still be able to successfully
read the whole file

b) when building the bundle for transmission or stripping, we'll report
a chunk size modulo 2G, which will be interpreted as a negative number
and thus look like an empty chunk.

[Erik Muttersbach]

Thanks for your information and support!

Finally, is there a chance to recover at least the other files from the bundle?

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 21:33 +0100, Erik Muttersbach wrote:
> The size of the uncompressed file is actually only about 750mb, so I
> think my large files may not be included there, However, I can see in
> the very beginning of the uncompressed bundle file a line that
> contains the path to one of these big files.
>
>
> Is there a manual way to decode the binary chunks?

Each chunk is of the form:

4 bytes: start
4 bytes: end
4 bytes: length
length bytes: data

..and instructs Mercurial to replace the bytes from start to end of the
previous version with the bytes from data.

--
Mathematics is the supreme nostalgia of our time.

[Erik Muttersbach]

Alright, I understood that, but, shouldn't I see the changes made in the files (the data) as real text if i open it with bless or vi?

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 22:44 +0100, Erik Muttersbach wrote:
> Alright, I understood that, but, shouldn't I see the changes made in
> the files (the data) as real text if i open it with bless or vi?

Yes.

[Erik Muttersbach]

Okay, I don't, so I think I will not be able to recover the data. Too bad - I think this is a major bug!

Erik

[Matt Mackall]

On Mon, 2010-11-29 at 22:50 +0100, Erik Muttersbach wrote:
> Okay, I don't, so I think I will not be able to recover the data. Too bad - I think this is a major bug!

As best I can tell, if you successfully decompressed the bundle, the
data should be well-correlated with the contents of your repo, modulo
some truncations.