[Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend

SourceForge.net noreply@sourceforge.net
Thu, 10 Jul 2003 13:00:51 -0700


Patches item #766650, was opened at 2003-07-06 13:09
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
>Assigned to: Martin v. Löwis (loewis)
Summary: whichdb not ID'ing dbm files with GDBM backend

Initial Comment:
For the OS/2 EMX port, I build the dbm module with gdbm
v1.7.3.

At least with the OS/2 version of the gdbm v1.7.3 port,
dbm databases consist only of the .pag file - there is
no .dir file.

In this case, the .pag file has the gdbm magic number.

Currently whichdb fails to identify such dbm DBs on
this platform because of the expectation that there be
a .dir file as well as the .pag file.

I'm not in any position to confirm whether the dbm
module built with gdbm behaves the same way on other
systems -information gratefully received on this topic.

On the assumption that other platforms also have this
behaviour, the attached patch attempts to detect
whether a dbm DB has a gdbm signature just by checking
the magic number of the .pag file.

The patch involves a refactoring of the magic number
code, which may be deemed inappropriate.

It may be more expedient to just special case theEMX
port in the dbm detection (by skipping looking for the
.dir file on this platform).

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-07-10 15:02

Message:
Logged In: YES 
user_id=250749

I've added a revised patch that attempts to address Martin's
points.

I've also added a patch that applies a workaround solely for
the only platform (OS/2 EMX) known to me to have this issue,
rather than trying to be fancy and all-encompassing.

I incline to the view that the platform specific workaround
would be safer for 2.3, with the more sophisticated approach
added after  the 2.3 release if appropriate.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-08 00:05

Message:
Logged In: YES 
user_id=21627

The dbm module greatly varies in behaviour across platforms,
depending on what underlying library is linked. On my Linux
installation, the resulting files are identified as

/tmp/u.dir: GNU dbm 1.x or ndbm database, little endian
/tmp/u.pag: GNU dbm 1.x or ndbm database, little endian

I recommend that you adjust your patch to take dbm.library
into account, and go looking for gdbm magic only if you find
that dbm is linked with gdbm.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470