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

Edit report at https://bugs.php.net/bug.php?id=68935&edit=1 ID: 68935 Comment by: cmbecker69 at gmx dot de Reported by: mattsch at gmail dot com Summary: fwrite won't recreate deleted file or emit warning 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: > BTW, is it possible to rename opened files under windows? No: $f = fopen('foo', 'w'); rename('foo', 'bar'); Warning: rename(foo,bar): Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. [The process can't access the file, because it's used by another process.] It seems to me that several file operations work quite differently on *nix and Windows, and that these differences deserve better documentation in the PHP manual. Previous Comments: ------------------------------------------------------------------------ [2015-01-30 01:08:47] yohgaki@php.net > 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. Then, we have issue with garbages. BTW, is it possible to rename opened files under windows? ------------------------------------------------------------------------ [2015-01-29 22:43:59] danack@php.net 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. ------------------------------------------------------------------------ [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> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68935 -- Edit this bug report at https://bugs.php.net/bug.php?id=68935&edit=1