severity 521860 grave quit On Fri, Apr 03, 2009 at 06:29:10AM +0000, Clint Adams wrote: > - if (PGNO(meta) == PGNO_BASE_MD && !F_ISSET(dbp, DB_AM_RECOVER)) > + if (PGNO(meta) == PGNO_BASE_MD && meta->dbmeta.last_pgno > 0 && > !F_ISSET(dbp, DB_AM_RECOVER))
> + hcp->hdr->dbmeta.last_pgno > 0 && So for me, on a v7 hash created with db3_load 3.2.9+dfsg-0.1, db4.7_dump will corrupt the database file unless either -r or -R are specified. With a v8 btree, a db4.7_dump -p will output correctly but a db4.7_dump -d a will not. In either case, dumping the v8 btree does not appear to lead to data loss. a db4.7_verify on the v7 hash gives an error about an impossible max_buckets setting in the metadata page. It does this because it in the partially-quoted patch above, it clobbers the last_pgno setting and compares 1, for instance, against 0 instead of 2. I don't know if this fix is comprehensive and I don't know what it breaks. I will attempt to escalate this to Oracle. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
