This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: anydbm and 'n' flag
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: jackiem, jafo
Priority: normal Keywords:

Created on 2005-05-31 19:32 by jackiem, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (2)
msg25456 - (view) Author: Jack Moffitt (jackiem) Date: 2005-05-31 19:32
 When a 0 length file exists and anydbm is asked to
create a new database with that file name via the
anydbm.open(fn, 'n') call, the call fails as whichdb
detection fails.

whichdb should not be invoked with the 'n' flag, since
the purpose of this flag is to always create a
database, not only if it is missing.

This bug prevents creating a secure temporary file with
mkstemp and then uisng that file to open a database. 
The workaround is to unlink the file then call open,
but this is leaving a small hole.
msg25457 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2005-06-01 03:00
Logged In: YES 
user_id=81797

I'm torn as to what should happen here.  In the
documentation, it says that in the event that the file
exists, the whichdb module will be used to determine the
type of the database.  In the case of an unrecognised
database format, that function returns the empty string, and
anydbm raises that as an exception.  On the other hand, the
documentation says that if "n" is passed a new database will
always be created, which in this case it definitely is not.

I'd be reluctant to change anydbm.open(), since the reason
for anydbm to exist is that it determines the database type
of an existing file, and in the case that it doesn't
understand the database type it says so.  One could imagine
a "textdb" type being added later where an empty file would
be a valid, empty, textdb file, but a change to anydbm here
could lead to problems in the future.

The real solution, I would propose, is that in the event
that you're trying to create a temporary database, call
mkstemp, then call "anydbm._defaultmod.open" on the
resulting file name, for example.  Call the module directly
instead of relying on anydbm.

I'm inclined to close this as Wont Fix, please re-open if
you think the assessment is wrong.

Sean
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 42037
2005-05-31 19:32:00jackiemcreate