|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30957 filesystem functions bugs in destructor (under gc condition)
Submitted: 2004-12-02 11:01 UTC Modified: 2005-01-31 01:00 UTC
Avg. Score:4.7 ± 0.6
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:7 (70.0%)
From: rueycheng at gmail dot com Assigned:
Status: No Feedback Package: Class/Object related
PHP Version: 5.0.1 OS: Windows XP
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2004-12-02 11:01 UTC] rueycheng at gmail dot com
Some filesystem functions, like file_put_contents() or fwrite(), don't work properly in the destructor __destruct().  The following scenario may looks a bit weird: it appeared that the file is not overwritten or even created, but PHP does 'read' the content of the imaginary file!

If you uncomment the last line of the code, everything would works fine.


$ diff php.ini php.ini-dist
< error_reporting  =  E_ALL
> error_reporting  =  E_ALL & ~E_NOTICE & ~E_STRICT
< include_path = ".;c:\php-5.0.1\PEAR"
> ;include_path = ".;c:\php\includes"
< extension_dir = "c:\php-5.0.1\ext"
> extension_dir = "./"
< extension=php_mbstring.dll
< extension=php_mcrypt.dll
< extension=php_mhash.dll
> ;extension=php_mbstring.dll
> ;extension=php_mcrypt.dll
> ;extension=php_mhash.dll
< extension=php_mysql.dll
> ;extension=php_mysql.dll

Reproduce code:
class Bug
	private $filename;
	public function __construct($filename) {
		$this->filename = $filename;
	public function __destruct() {
		echo "[";
		file_put_contents($this->filename, 'Gotcha!');
		echo file_get_contents($this->filename);
		echo "]";

$bug = new Bug('.bugtest');

Expected result:

(And the file .bugtest under working directory should be created.)

$ cat .bugtest

Actual result:

$ cat .bugtest
cat: .bugtest: No such file or directory


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-02 11:25 UTC] rueycheng at gmail dot com
The garbage collector may clean up the object prior to its __destruct() invocation.  Nothing would go wrong if you explicitly *destroy* the object.

By the way, I tested the code on Redhat 7.3 with the following configuration.  

$ cat config.nice
#! /bin/sh
# Created by configure

'./configure' \
'--with-apxs=/usr/local/apache/bin/apxs' \
'--with-mysql=/usr/local/mysql/' \
'--with-libxml-dir' \
'--enable-dba' \
'--enable-mbstring' \

$ diff php.ini ../src/php-5.0.1/php.ini-recommended
< display_errors = On
> display_errors = Off
< ;error_log = /var/log/php.log
> ;error_log = filename
< include_path = ".:/usr/local/lib/php"
> ;include_path = ".:/php/includes"

As a result, two warnings are generated.

Warning: file_put_contents(./.bugtest) [function.file-put-contents]: failed to open stream: Permission denied in /home/httpd/html/testbed/bugtest.php on line 12

Warning: file_get_contents(./.bugtest) [function.file-get-contents]: failed to open stream: No such file or directory in /home/httpd/html/testbed/bugtest.php on line 13

Actually I've already enabled the write-permission for the directory.  The execution of these filesystem functions outside of __destruct() is OK.
 [2004-12-13 03:09 UTC] iquito at gmx dot ch
I also encountered this bug, it is very annoying - a class of mine checks a file with a simple file_exists(), and the file isn't found - the whole script works if I call the destructor at the very end of it explicitly (which isn't really the point of having a destructor). it seems no file functions work at all in the destructor. This bug also applies to register_shutdown_function, it just seems that as soon as the "regular" scripts stops, everything that comes after that has problems with the file system.
 [2005-01-12 02:03 UTC]
Please try using this CVS snapshot:
For Windows:

Can't reproduce under Linux. 
Please, try the snapshot.
 [2005-01-31 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 22:01:31 2024 UTC