php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #16424 dba_*open "c" mode broken again
Submitted: 2002-04-04 04:59 UTC Modified: 2002-05-25 09:06 UTC
From: tmo at virtua dot ch Assigned:
Status: Closed Package: DBM/DBA related
PHP Version: 4.1.2 OS: trustix (rh 6.2 based)
Private report: No CVE-ID: None
View Developer Edit
 [2002-04-04 04:59 UTC] tmo at virtua dot ch 
I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore.
Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file.

I'm using with an compiled sleepycat 4.0.14 db3 implementation.

php configure command:
//---
./configure 
--with-apxs=/usr/local/apache/bin/apxs 
--with-openssl 
--enable-bcmath 
--enable-calendar 
--enable-ctype 
--enable-ftp 
--enable-imgstrttf 
--with-ttf 
--with-imap 
--with-imap-ssl  
--enable-trans-sid 
--enable-shmop 
--enable-sockets 
--enable-sysvshm 
--with-pgsql=/usr/local/pgsql 
--with-gd=/usr/local 
--with-mysql 
--with-mcrypt=/usr/lib/libmcrypt 
--with-mssql=/usr/local/freetds 
--with-sybase=/usr/local/freetds 
--with-gdbm 
--with-db3=/usr/local/BerkeleyDB.4.0/  
--enable-dba
//---

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-04 06:40 UTC] tmo at virtua dot ch 
I've found reply as this bug has been fixed in 4.0.6, but it isn't
anymore.
Using a dba_open in mode "c" will create the file if it doesn't exists,
but will fail in opening an existing file.

I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation.

php configure command:
//---
./configure 
--with-apxs=/usr/local/apache/bin/apxs 
--with-openssl 
--enable-bcmath 
--enable-calendar 
--enable-ctype 
--enable-ftp 
--enable-imgstrttf 
--with-ttf 
--with-imap 
--with-imap-ssl  
--enable-trans-sid 
--enable-shmop 
--enable-sockets 
--enable-sysvshm 
--with-pgsql=/usr/local/pgsql 
--with-gd=/usr/local 
--with-mysql 
--with-mcrypt=/usr/lib/libmcrypt 
--with-mssql=/usr/local/freetds 
--with-sybase=/usr/local/freetds 
--with-gdbm 
--with-db3=/usr/local/BerkeleyDB.4.0/  
--enable-dba
//---
 [2002-04-04 07:04 UTC] sniper@php.net 
And what was the bug number where it says this is fixed?
 [2002-04-04 07:11 UTC] tmo at virtua dot ch 
sorry, forgot it.
It was referenced by n?10380 and 13629.

Both are refernced as closed.
 [2002-04-04 07:19 UTC] sniper@php.net 
I just tried the example code found in #13629 and it works
fine with PHP 4.2.0RC2 (found at http://www.php.net/~derick/)

But I've compiled PHP with db-3.3.11.
 [2002-04-04 07:37 UTC] tmo at virtua dot ch 
The problem is that our firm policy is only to use stable release on production servers. 

And as I found some complaint on newsgroup about this bug since upgrading php lately (~10 of march), I thought it may have passed through.
Maybe the 3.x to 4.x BerkeleyDB code changed again, as described in #13629.
Because copy/paste of the example given in #13629 fail on the second access, and succeed again when the db file is erased on my dev box.

For myself, I already wrote a small check lib which give me back the access type to use. So this issue isn't a big one, and if it works with the next release, nothing to worry about.
Beside, I haven't tried to downgrade my DB3 lib to 3.x, I prefer stay up to date with today libs.
 [2002-05-25 09:06 UTC] derick@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Dec 07 01:00:01 2025 UTC