Bug 2972 - Berkeley DB version not backward compatible to earlier RH versions
Summary: Berkeley DB version not backward compatible to earlier RH versions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL: www.mailbr.com.br , www.mollymail.com
Whiteboard:
: 2619 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-22 21:45 UTC by ricardo
Modified: 2008-05-01 15:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-07-09 15:03:15 UTC
Embargoed:


Attachments (Terms of Use)

Description ricardo 1999-05-22 21:45:35 UTC
Although RedHat 6.0 provides both the db_dump and
db_dump185
utilities for the Berkeley DB installation, the db_dump185
does NOT work.

We have a service which relies on many thousands of
user-specific db files, and these db files were created on
linux systems using RedHat 5.x series. The Berkeley DB
distribution on these systems is older compared to RedHat
6.0. RedHat 6.0 creates db files with the following
signature:

File Type:              Berkeley DB Hash file.
File Version ID:        5
Built with Berkeley DB: 2.2.6 or greater
Byte Order:             Little Endian
Magic:                  061561

RedHat 5.x systems create db files with this signature:

File Type:              Berkeley DB Hash file.
File Version ID:        2
Built with Berkeley DB: 1.71 -> 1.85
Byte Order:             Unknown
Magic:                  061561

RedHat 6.0 systems provide the db_dump185 utility, which is
supposed to dump out older db files. This is a method to
convert older file types to the new one, since the default
Berkeley DB in RedHat 6.0 CANNOT read older db files.
However the db_dump185 version in RH 6.0 DOES NOT WORK.
Here's an example output:

# db_dump185 /dmail/dbs/mailbr.com.br
db_dump185: /dmail/dbs/mailbr.com.br: Invalid argument

The above file /dmail/dbs/mailbr.com.br was one of the
files
created in the older 5.x systems.

This is an item of urgency for us. We handle to busy
webmail
services which rely on Berkeley DB files, one of them
having
roughly 150,000 db files created with RH 5.x and we're
about
to migrate to RH 6.0. The other site also relies heavily on
roughly 20,000 db files.

Thank you and we look forward to a quick resolution of this
problem

Ricardo Kleemann
AmericasNet Internet

Comment 1 Jeff Johnson 1999-05-23 15:39:59 UTC
The db_dump185 in glibc appears to have been linked with -ldb rather
than -ldb1.

I have packaged the latest db-2.7.5 and verified that I can do
db_dump185 on the db1 files in the rpm database. Please send me
mail (jbj) verifying that you can receive an attached
binary rpm and I will send you a copy of the binary and/or source
rpms that include that db_dump185.

This is just a workaround; the eventual fix will be in glibc.

Comment 2 Jeff Johnson 1999-05-23 15:46:59 UTC
The db_dump185 in glibc appears to have been linked with -ldb rather
than -ldb1.

I have packaged the latest db-2.7.5 and verified that I can do
db_dump185 on the db1 files in the rpm database. Please send me
mail (jbj) verifying that you can receive an attached
binary rpm and I will send you a copy of the binary and/or source
rpms that include that db_dump185.

This is just a workaround; the eventual fix will be in glibc.

------- Email Received From  Ricardo Kleemann <ricardo> 05/23/99 12:53 -------

Comment 3 David Lawrence 1999-06-01 22:43:59 UTC
*** Bug 2619 has been marked as a duplicate of this bug. ***

The Open Group's UNIX spec clearly states that there
should exist a file /usr/include/ndbm.h.  Now I understand
there's some controversey over which database to use
GNU or BSD, but a decision must be made. There must be
a <ndbm.h> file.  <db1/ndbm.h> does not make the standard.
(my pick would be the (GNU) gdbm version of ndbm.)


------- Additional Comments From ct7  05/12/99 17:28 -------
reviously RedHat shipped this in glibc-devel-2.0.7-29.i386.rpm; why
isn't it being shipped now in glibc-devel-2.1.1-6.i386.rpm?  This is a
lousy way to treat people who are upgrading from previous versions --
I'm sure I could go back through all of my older RH5.X disks and find
that ndbm.h was in /usr/include ... why move it now?

The GPL license shouldn't be an issue since the GNU libraries are
being delivered as part of the base operating system.

Comment 4 Jeff Johnson 1999-06-18 00:26:59 UTC
db_dump185 needs to be linked with -ldb1

Comment 5 Cristian Gafton 1999-07-09 15:03:59 UTC
In glibc-2.1.2-1 the db_dump185 binary is linked against the right db
library (db1). Package will show up on rawhide shortly.


Note You need to log in before you can comment on or make changes to this bug.