Bug #68935 [Opn]: fwrite won't recreate deleted file or emit warning

From: Date: Thu, 29 Jan 2015 15:02:19 +0000
Subject: Bug #68935 [Opn]: fwrite won't recreate deleted file or emit warning
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-190306@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68935&edit=1 ID: 68935 User updated by: mattsch at gmail dot com Reported by: mattsch at gmail dot com Summary: fwrite won't recreate deleted file or emit warning Status: Open Type: Bug Package: Filesystem function related Operating System: Gentoo Linux 13.0 PHP Version: 5.6.5 Block user comment: N Private report: N New Comment: So if this a documentation fix, then in order to ensure a link in the filesystem, I will have to check if the file exists before calling fwrite and if not, null the resource and open a new one and write to the new one. Previous Comments: ------------------------------------------------------------------------ [2015-01-29 05:12:16] phpmpan at mpan dot pl I believe this is just a misunderstanding around a difference between a file not existing and a file not having an entry within a filesystem. The behaviour is fine. While it may not be the case for PHP web applications, in general it is not a very uncommon scenario to change/delete filename while a file associated with it is still open. See IPC based on temporary named pipes as an example. However, documentation for unlink should notify the reader about the behaviour. Indeed it may be a bit surprising for Windows users. ------------------------------------------------------------------------ [2015-01-28 20:56:56] cmbecker69 at gmx dot de The manual[1] states that unlink is similar to the Unix unlink() function. man unlink(3) states[2]: | The unlink() function shall remove a link to a file. | [...] | When the file's link count becomes 0 and no process has the file | open, the space occupied by the file shall be freed and the file | shall no longer be accessible. If one or more processes have the | file open when the last link is removed, the link shall be removed | before unlink() returns, but the removal of the file contents | shall be postponed until all references to the file are closed. This would explain the reported behavior. Maybe all this is just a documentation issue. FWIW: on Windows it is not possible to unlink a file with an open handle. [1] <http://php.net/manual/en/function.unlink.php> [2] <http://linux.die.net/man/3/unlink> ------------------------------------------------------------------------ [2015-01-28 15:29:55] mattsch at gmail dot com Changed the summary to include the other potential expected result. ------------------------------------------------------------------------ [2015-01-28 15:27:48] mattsch at gmail dot com Description: ------------ Open/create a file with fopen. Then delete the file with unlink. Finally, write to that already opened resource with fwrite. fwrite reports the number of bytes written without any errors but the file no longer exists so nothing is actually written to a file. One of two options should happen: 1. fwrite should emit a warning and report bytes written as false or 2. fwrite should recreate the deleted file and write to it and report the bytes written. Test script: --------------- <?php $resource = fopen('foo', 'w'); unlink('foo'); $bytesWritten = @fwrite($file, 'bar'); $error = error_get_last(); var_dump($error); var_dump($bytesWritten); var_dump(file_exists('foo')); Expected result: ---------------- array(4) { ["type"]=> int(2) ["message"]=> string(58) "fwrite(): cannot write to file because file no longer exists" ["file"]=> string(27) "/home/foo/foo.php" ["line"]=> int(4) } bool(false) bool(false) --or-- NULL int(3) bool(true) Actual result: -------------- NULL int(3) bool(false) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68935&edit=1

« previous php.bugs (#190306) next »