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

Edit report at https://bugs.php.net/bug.php?id=68935&edit=1 ID: 68935 Updated by: danack@php.net Reported by: mattsch at gmail dot com Summary: fwrite won't recreate deleted file or emit warning -Status: Open +Status: Not a bug 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: mattsch that is correct. If something on your machine is unlinking files that you are currently writing to, then you need to check to see if that has happened. I would suggest merely renaming the file instead of deleting it, to allow a new file to be created in it's place, and for any writes to existing handles proceed to the renamed file. Previous Comments: ------------------------------------------------------------------------ [2015-01-29 15:02:18] mattsch at gmail dot com 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. ------------------------------------------------------------------------ [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