[Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files
with GDBM backend
SourceForge.net
noreply at sourceforge.net
Wed Dec 3 06:42:07 EST 2003
Patches item #766650, was opened at 2003-07-06 21:09
Message generated for change (Settings changed) made by aimacintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470
Category: Modules
Group: Python 2.4
>Status: Closed
Resolution: Works For Me
Priority: 3
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Andrew I MacIntyre (aimacintyre)
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-12-03 22:26
Message:
Logged In: YES
user_id=250749
I can't confirm this for sure, not having gdbm installed on
my FreeBSD box, but I think that gdbm actually has only one
DB file, but creates a hard link to show both filenames.
Because EMX doesn't support link(), the hard link can't be
created, and so the gdbm just creates one of the 2 expected
files.
At this point I don't think this is worth pursuing any
further, as the EMX specific workaround meets the
requirement, and no other platforms appear to be having
problems.
Therefore I am closing this patch as not requiring any
further action.
----------------------------------------------------------------------
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-07-11 22:21
Message:
Logged In: YES
user_id=250749
OS/2 EMX specific workaround applied to whichdb.py as v1.17.
Re-grouped to 2.4; lowered to priority 3.
I'll prepare a version of the revised "complete" patch to
take into account application of the EMX workaround after
2.3 is out the door.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-11 07:09
Message:
Logged In: YES
user_id=21627
I agree that the more conservative patch is better at this
point; please apply it. The regroup the patch for 2.4 and
leave it open (perhaps at a lower priority also).
----------------------------------------------------------------------
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-07-10 23: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 08: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
More information about the Patches
mailing list