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.

Author denversc
Recipients denversc
Date 2011-03-14.06:42:41
SpamBayes Score 1.6486812e-14
Marked as misclassified No
Message-id <1300084962.92.0.477782999731.issue11491@psf.upfronthosting.co.za>
In-reply-to
Content
dbm.open() with flag="n" raises dbm.error if the given file exists but whichdb doesn't recognize it.  In the documentation for dbm.open() the "n" flag is documented to "Always create a new, empty database, open for reading and writing".  To me, this implies that if the file exists it will unconditionally be overwritten with a newly-created database, irrespective of its contents.

The code below illustrates a scenario (and indeed the scenario that I ran into) where dbm.open(..., flag="n") will throw dbm.error when it should just blow away the existing file and create a new, empty database:

import dbm
open("test.db", "w").close() # create empty file
dbm.open("test.db", flag="n")

The cause of the exception is that within dbm.open() there is a call to whichdb to determine the file type.  The fix would be to skip this whichdb check if the "n" flag is specified.

I don't think that this change will cause backward compatibility issues, since I find it hard to believe that existing applications would rely on this exception being raised in this scenario.  However, to *guarantee* no compatibility break an alternate fix could leave the current behavior of the "n" flag and introduce a new flag, perhaps "o" for "overwrite", with this "unconditional overwrite" behavior.

A proposed patch is attached: dbm_open_n_flag_error_invalid_file_fix_v1.patch
History
Date User Action Args
2011-03-14 06:42:43denverscsetrecipients: + denversc
2011-03-14 06:42:42denverscsetmessageid: <1300084962.92.0.477782999731.issue11491@psf.upfronthosting.co.za>
2011-03-14 06:42:42denversclinkissue11491 messages
2011-03-14 06:42:42denversccreate