Very interesting.
Both of them look fairly sane as objects (ie random - it's supposed to eb
zlib-compressed), but both of them have the first 512 bytes *identically*
corrupted:
0000000 6564 626e 6575 406e 6f64 6f72 6874 2e79
d e n b u e n @ d o r o t h y .
0000020 6f6c 6163 2e6c 3634 0033 0000 0000 0000
l o c a l . 4 6 3 \0 \0 \0 \0 \0 \0 \0
0000040 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
ie it's an all-zero block, except for that email-looking thing at the
head.
Sadly, I don't think there is any way to find the missing block that got
overwritten. And quite frankly, there's no way to really know whether the
rest was really fine either - it just looks more likely, but quite
frankly, it could have been random old contents on your disk too that just
happens to look like the expected random pattern (which you'll get with
any compression format - compression by definition removes patterns).
One thign that strikes me is that you seem to be really prone to this
problem, since it happened to you a year ago too. I cannot swear to this,
but I literally suspect your last case (July-2007) was the previous time
we had a corruption issue. Why does it seem to happen to you, but not
others?
Do you have some odd filesystem in play? Was the current corruption in a
similar environment as the old one? IOW, I'm trying to find a pattern
here, to see if there might be something we can do about it..
But it *sounds* like the objects you lost were literally old ones, no? Ie
the lost stuff wasn't something you had committed in the last five minutes
or so? If so, then you really do seem to have a filesystem that corrupts
*old* files when it crashes. That's fairly scary. What FS is it?
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
