Doc #67105 [Ver->Csd]: tmpfile() may not remove the temporary file
| From: | cmb@php.net | Date: | Fri, 28 Dec 2018 23:28:44 +0000 |
| Subject: | Doc #67105 [Ver->Csd]: tmpfile() may not remove the temporary file | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-16247@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=67105&edit=1
ID: 67105
Updated by: cmb@php.net
Reported by: nate at frickenate dot com
Summary: tmpfile() may not remove the temporary file
-Status: Verified
+Status: Closed
Type: Documentation Problem
Package: Filesystem function related
Operating System: Ubuntu 14.04
PHP Version: Irrelevant
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation better.
Previous Comments:
------------------------------------------------------------------------
[2018-12-28 23:27:50] cmb@php.net
Automatic comment from SVN on behalf of cmb
Revision: http://svn.php.net/viewvc/?view=revision&revision=346471
Log: Fix #67105: tmpfile() may not remove the temporary file
------------------------------------------------------------------------
[2018-12-28 23:22:20] cmb@php.net
> The documentation for the tmpfile() function is wrong and misleading:
ACK.
> Php devs are used to a C-named function being C-equivalent, and
> it causes problems when this is not the case.
While some PHP functions are âinheritedâ from C, few are actually
simple wrappers; for instance, PHP's string functions are supposed
to be binary safe while C works with zero terminated strings. You
should not rely on eponymous functions to behave exactly as
specified by POSIX or C.
------------------------------------------------------------------------
[2014-04-22 00:54:08] nate at frickenate dot com
Description:
------------
The documentation for the tmpfile() function is wrong and misleading:
"The file is automatically removed when closed (for example, by calling fclose(), or when there
are no remaining references to the file handle returned by tmpfile()), or when the script ends.
For details, consult your system documentation on the tmpfile(3) function, as well as the stdio.h
header file."
The fact is php does *not* use tmpfile(3) for its implementation. That C function *guarantees* that
there will not be a temporary file left on disk once the program exists, as the file is unlinked
even before tmpfile(3) even returns.
However, as php relies on its own internal implementation of temporary files instead of using
tmpfile(3), not only is the file not unlinked before returning the handle, but zombie files on disk
are possible. This is shown in the attached test script.
Please update the documentation to not only remove the misleading information about tmpfile(3), but
to explicitly state and warn that the function does *not* use tmpfile(3). Php devs are used to a
C-named function being C-equivalent, and it causes problems when this is not the case.
Test script:
---------------
<?php
// 1. run this script from command-line, do steps 2 and 3 while sleeping.
// 2. check temp directory. file exists, would not be the case with tmpfile(3).
// 3. ctrl+c quit the running script. temp file is zombied, not unlinked.
$fh = tmpfile();
sleep(500);
Expected result:
----------------
Technically, I would expect php's tmpfile() to use tmpfile(3). However, I have seen existing
code using tmpfile() and then stream_get_meta_data() to extract the 'uri' argument to
manipulate the file on disk (ex: using it with ZipArchive::open()). Since a proper tmpfile(3)
implementation would result in no accessible file on disk, this type of code would break.
So instead update the documentation to reflect that tmpfile() does not use tmpfile(3) and that
zombie temporary files are possible if php exits unexpectedly.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=67105&edit=1