Revision history for Perl extension DB_File::Lock. 0.05 Tue Apr 9 15:14:43 EDT 2002 - removed use Carp qw(verbose) which was effecting other modules - documentation improvements recommended by Stas Bekman <firstname.lastname@example.org> - the documentation said we supported RECONO (tie for arrays) but Shlomo Yona <Shlomo.Yona@Siftology.com> pointed out the implementation did not support that. Added support for RECNO. - added a warning when opening a database with write access and only locking it for reading. This warning disabled for RECNO because RECNO seems to require O_RDWR even when opening only for reading. - added test of database creation failure - added test of database access through object interface - added test of RECNO database creation and usage 0.04 Fri Aug 11 09:08:48 EDT 2000 - Three good fixes from Robert Mathews <email@example.com>. (Thanks to him for submitting a patch!) In his own words: (1) The first one is nothing big: test 16 fails with BerkeleyDB v1.85 on solaris 5.6. This seems to be due to the fact that we're creating a database (and therefore writing to it), but it's only read-locked. (2) The second is that TIEHASH assumes that SUPER::TIEHASH will succeed. If it doesn't, the lockfile gets left open, and DESTROY is never called to close it. (3) I ran into one other issue: umask isn't restored if sysopen on the lockfile fails. Fixed that too. 0.03 Wed Feb 2 11:06:08 EST 2000 - stupid me! version 0.02 didn't ship with a Makefile.PL, only a Makefile.old. seems that I deleted the wrong file before taring up the archive after testing. - Lock.pm didn't have $VERSION set correctly. 0.02 Thu Jan 13 20:19:44 EST 2000 - much improved documentation - much improved README - added notes to other DB_File wrapper locking functions in POD and README - fixed some incorrect assumptions about flock(2) in test.pl that ended up being wrong on both Solaris and HP-UX and caused two tests to fail. 0.01 Sat Jan 1 23:39:30 EST 2000 - original version; created by h2xs 1.19 - based on origional DB_Lock from http://www.davideous.com/misc/DB_Wrap.pm and some helpful insight from Stas Bekman <firstname.lastname@example.org>.