[ZODB-Dev] Re: Can't pack ZODB anymore

[Tim Peters]

[aku at europe.com]
> tried copyTransactionsFrom() method Tim suggested, started with an empty
> Data.fs (good) and copied all the transactions from my existing Data.fs
> (bad).

I showed you exactly the code I used, but no English description can be that
precise.  I can't really know what you did.

> Full of hope I ran fstest on the new Undamaged.fs, but unfortunately:
> time-stamp error :( I looked at the code in copyTransactionsFrom(), but
> don't know enough about ZODB to check whether that code is correct.

Please show the exact code you used, as a little Python program.  It's only
a few lines of code.  Note that I didn't start with "an empty Data.fs",
there was no file named Undamaged.fs when I started.  The code I showed
created Undamaged.fs from scratch.  BTW, did fstest give *exactly* the same
complaint about Undamaged.fs as it gave for the original Data.fs?  Or did it
change (by even one character)?

> BTW: The reason for the system clock going backwards is simple: I ran an
> old trial version of Vmware that was expired. I therefore had to set the
> clock backwards a couple of months. After a day or so, I restored the
> system clock.

Eek.  That would explain it, but I'm not sure it's wise to admit to illegal
activity on a public mailing list <0.9 wink>.

> I guess I could try fsrecover.py now, even though I loose (hopefully only
> a few days) of data ?

If you look at fsrecover.py, you'll find the timestamp-fiddling code to be
very familiar now.  It looks like someone copy-and-pasted this code from (or
to) copyTransactionsFrom().  I find it hard to believe that the latter
method doesn't work when used correctly.  But if there's a bug and it in
fact doesn't work, then I expect that fsrecover.py has the same bug.

Would it be possible for me to get a copy of your damaged Data.fs?