Doc #67105 [Ver->Csd]: tmpfile() may not remove the temporary file

From: 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&amp;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

« previous php.doc.bugs (#16247) next »