This content has been marked as final. Show 11 replies
Can you provide the details of what you are doing
at each step here and what error messages, etc, you
are receiving at each point. Also what is the platform/
version you are based on.
The following is with db 3.2.9 and db 4.7.25:
/db3.2.9/db_load -t hash -T v7hash.db <dataset
cp v7hash.db corruption.db
/db4.7.25/db_dump -d a corruption.db
cmp -lb v7hash.db corruption.db
This is on Debian amd64.
Could you tell us what exactly the problem is?
Are you just surprised that db_dump is changing the "corruption.db" database? What are you attempting to do with the "corruption.db" after the db_dump that fails?
I'll get back to you about the verify patch tomorrow.
Oracle Berkeley DB
I am confused about why it is modifying the database at all, but especially why it is deleting all the data.
I've just spent time attempting to reproduce the issue you have reported. I am not able to.
I have built a version of 4.3.29 and 4.7.25, including the Tcl library. Then run:
$ cd db-4.3.29/build_win32/Debug
$ echo "source ../../test/test.tcl; eval test001 hash" | tclsh84g.exe
$ cd ../../../db-4.7.25/build_windows/Debug
$ mkdir dump_test
$ cp ../../../db-4.3.29/build_win32/Debug/TESTDIR/test001.db dump_test/db_43.db
$ cp dump_test/db_43.db dump_test/alter.db
$ ./db_dump dump_test/alter.db > /dev/null
$ cmp dump_test/db_43.db dump_test/alter.db
The first two commands are creating a database. The db_dump utility from 4.7 was able to dump the contents of the database created using DB 4.3. The dumped file was not altered after db_dump was run.
I was running this on Windows, using Cygwin. There is no reason why the behavior would be platform dependant.
I also attempted to recreate the failure using a database created with db_load in 4.3. There was no failure.
If you can provide a more concrete reproducible example, I'll happily investigate further.
Berkeley DB engineer
4.7's db_verify on the v7 hash gives an error about an impossible max_buckets setting in the metadata page.I also can't reproduce this failure.
It seems to do this because it clobbers the last_pgno setting and compares 1, for instance, against 0 instead of 2.
I don't think the patch you supplied is the correct solution. If the retrieved metadata has a last_pgno of 0, then the database has been corrupted.
Can you provide a reproducible test case, or at least a stack trace of the failure?
Does db4.3 produce a version 7 hash on Windows? It produces a version 8 hash on unix, which is why I had to use db3.2.9 to reproduce this problem.
Sorry for my earlier reply. I must have been having a vacant day.
I can reproduce the problem with Berkeley versions 3.2.9 and 4.7.25. I will investigate further and let you know what I find.
Oracle Berkeley DB
Hi there... 16 months have passed by, can we assume that someone will eventually look into this issue?
This bug is affecting our users upgrading to Debian squeeze and we still would like to have a fix in some .point release if possible.