|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #64811 SplTempFileObject doesn't provide valid return values for SplFileInfo / filenam
Submitted: 2013-05-10 11:20 UTC Modified: 2021-07-29 14:56 UTC
Avg. Score:4.5 ± 0.6
Reproduced:12 of 12 (100.0%)
Same Version:2 (16.7%)
Same OS:10 (83.3%)
From: bugs+php at childno dot de Assigned:
Status: Verified Package: SPL related
PHP Version: 5.4.15 OS: Any
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: bugs+php at childno dot de
New email:
PHP Version: OS:


 [2013-05-10 11:20 UTC] bugs+php at childno dot de
the SplTempFileObject is intended to use the php://temp in-memory storage.
This has disadvantages if it is used for creating files on the fly that needed to be processed afterwards. Typically you want to provide SplFileInfo to certain interfaces that might handle and read the content again.

e.g. see

Test script:
$file = new \SplTempFileObject();
if ($file->fwrite("foo") !== null)
  print('wrote `' . $file->ftell() . '` byte(s) to `' . $file->getRealPath() . '`');
// wrote `3` byte(s) to ``
// ^^ thats ok for < 2MB while it is expected to be in-memory

$file = new \SplTempFileObject(0);
if ($file->fwrite("foo") !== null)
  print('wrote `' . $file->ftell() . '` byte(s) to `' . $file->getRealPath() . '`');
// wrote `3` byte(s) to ``
// NOT OK Because we set the limit to 0 to force writing stuff to the filesystem

$file = new \SplFileObject(tempnam(sys_get_temp_dir(), rand()), 'w+');
if ($file->fwrite("bar") !== null)
  print('wrote `' . $file->ftell() . '` byte(s) to `' . $file->getRealPath() . '`');

// wrote `3` byte(s) to `/tmp/2123740490ZwI6Qd`
// ^^ that's what I expect even for \SplTempFileObject(0)

Expected result:
\SplTempFileObject->getFileName() should return like `2123740490ZwI6Qd` \SplTempFileObject->getFileInfo() should return a valid SplFileInfo Object pointing to /tmp/2123740490ZwI6Qd 
\SplTempFileObject->getRealPath() should return like /tmp/2123740490ZwI6Qd

Actual result:
\SplTempFileObject->getFileName() will return php://temp \SplTempFileObject->getFileInfo() will return an empty object / file pointer \SplTempFileObject->getRealPath() will always return an empty string!


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-03-13 14:39 UTC] hudsonHatesSpam at gmail dot com
In my use case, I'm trying to build a temp file for a MySQL "LOAD DATA LOCAL INFILE".  I do not want the file to persist after the script has run, and there's no clear way to remove an SplFileObject at the end of the script.  My recourse was to use SplTempFileObject calling:

$tempFile = new \SplTempFileObject(0);

According to the documentation:

"public SplTempFileObject::__construct ([ int $max_memory ] )"
"If max_memory is zero, no memory will be used"

which forces the tempFile to be written to disk.  While I can see my temp file during script execution, I have no way of feeding the file URI to my SQL call.
 [2018-08-18 14:39 UTC]
SplTempFileObject is implemented as simple wrapper over php://temp
and php://memory, respectively,[1] and as such it's not possible
to get the actual filename AFAIK.  This is why ::getRealPath()
returns FALSE (it's not an empty string).

[1] <>
 [2021-07-29 14:56 UTC]
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2021-07-29 14:56 UTC]
On having a closer look, the behavior is unlikely to be
intentional.  SplTempFileObject::getFileName() returns the name of
the php:// wrapper, and ::getRealPath() returns false, because
realpath(php://temp) returns false; ::getPath(), however, returns
an empty string.

Still, changing this would be a BC break per se, but worse, the
change would need to be quite intrusive, since php://temp's
writing to temp is hidden in the stream wrapper and the actual
path to the temp file is ignored[1].  Given that the
implementation behaves this way since "forever"[2], we need to
document that behavior anyway.  Thus, changing to doc problem.
Could switch back to bug or feature request, after the docs have
been fixed.  I'm not sure how to fix the docs, though, since none
of these methods are actually overloaded, nor are there properties
to document.

[1] <>
[2] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jun 17 04:01:31 2024 UTC