[fossil-users] content does not mach sha1 hash

5 views
Skip to first unread message

Marco Maggesi

unread,
Aug 9, 2011, 8:25:04 AM8/9/11
to fossil...@lists.fossil-scm.org
Hello,

I have two fossil repositories (the "local" one and the "remote" one) and I get the following error when I try to pull:
"content does not mach sha1 hash"

So, first of all, I would like to establish if one or both repositories are corrupted.
Are there specific commands to check the integrity of a fossil repository?
I tried
fossil info
fossil rebuild
but none of them seems to be able to detect (nor fix) inconsistencies in my repositories.

I use fossil version 1.18 (on both machines).

Suggestions?

Thanks in advances.
Marco
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Richard Hipp

unread,
Aug 9, 2011, 8:39:30 AM8/9/11
to fossil...@lists.fossil-scm.org
On Tue, Aug 9, 2011 at 8:25 AM, Marco Maggesi <marco....@gmail.com> wrote:
Hello,

I have two fossil repositories (the "local" one and the "remote" one) and I get the following error when I try to pull:
 "content does not mach sha1 hash"

So, first of all, I would like to establish if one or both repositories are corrupted.
Are there specific commands to check the integrity of a fossil repository?

fossil test-integrity

There are a lot of "test" commands.  Do "fossil test-commands" to see them all.  But remember:  test-commands are unsupported, might not work, and might change or disappear at any moment.  So don't get emotionally attached to them.  If you really, really need a test-command to be supported, bring it up on this list and we will talk about promoting it regular command.
 
I tried
fossil info
fossil rebuild
but none of them seems to be able to detect (nor fix) inconsistencies in my repositories.

I use fossil version 1.18 (on both machines).

Suggestions?

Thanks in advances.
Marco
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
D. Richard Hipp
d...@sqlite.org

Marco Maggesi

unread,
Aug 9, 2011, 9:05:33 AM8/9/11
to fossil...@lists.fossil-scm.org
Thank you for your quick answer.

I run test-integrity and I found that both repositories are corrupted.
One says:

fossil: checksum mismatch on blob rid=58:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
01f57728b3a5d55520becb489146d0a7f42f9638

The other says:

skip phantom 177 ccc986b41c2a37fb86a8267d2dd0ac0b17e12bc9
fossil: checksum mismatch on blob rid=178:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
15e01a5726c26fe931d4b833215defd17ec9b3ae

Now what I am supposed to do to try to solve this situation?
Can I hope to recover from this inconsistency?
Thanks again.
M.


2011/8/9 Richard Hipp <d...@sqlite.org>:

Marco Maggesi

unread,
Aug 9, 2011, 9:12:24 AM8/9/11
to fossil...@lists.fossil-scm.org
Hi,
I found another copy of the same repository which is up to date and
doesn't have this inconsistency.
This solves my current problem.

BTW, these repositories are quite small (~120K).
If you think that they can be useful for debugging, I can send them to you.

Thank you for your support,
Marco

2011/8/9 Marco Maggesi <marco....@gmail.com>:

Richard Hipp

unread,
Aug 9, 2011, 9:16:30 AM8/9/11
to fossil...@lists.fossil-scm.org
On Tue, Aug 9, 2011 at 9:05 AM, Marco Maggesi <marco....@gmail.com> wrote:
Thank you for your quick answer.

I run test-integrity and I found that both repositories are corrupted.
One says:

fossil: checksum mismatch on blob rid=58:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
01f57728b3a5d55520becb489146d0a7f42f9638

da39a3ee5e6b4b0d3255bfef95601890afd80709 is the hash for a zero-length object.  Something is clearly messed up.

Can you send me both repos via private email so that I can investigate further?
 

Alaric Snell-Pym

unread,
Aug 9, 2011, 11:08:47 AM8/9/11
to fossil...@lists.fossil-scm.org
On 08/09/2011 02:16 PM, Richard Hipp wrote:

> da39a3ee5e6b4b0d3255bfef95601890afd80709 is the hash for a zero-length
> object. Something is clearly messed up.

As a general rule of thumb, whenever mysteriously zero-length files crop
up, the first thing I check is whether anything's run out of disk space
at any point...

...shortage of disk space can result in files being creatable (taking up
already-allocated space in inode tables and directory entries) but then
not being writable (leading to zero-length files).

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

Reply all
Reply to author
Forward
0 new messages