Bug #68935 [Opn]: fwrite won't recreate deleted file or emit warning
| From: | mattsch at gmail dot com | 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