php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
Votes:12
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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bugs+php at childno dot de
New email:
PHP Version: OS:

 

 [2013-05-10 11:20 UTC] bugs+php at childno dot de 
Description:
------------
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 
http://stackoverflow.com/questions/12555139

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 s.th. like `2123740490ZwI6Qd` \SplTempFileObject->getFileInfo() should return a valid SplFileInfo Object pointing to /tmp/2123740490ZwI6Qd 
\SplTempFileObject->getRealPath() should return s.th. 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!

Patches

Pull Requests

History

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 ] )"
and
"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] cmb@php.net 
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] <https://github.com/php/php-src/blob/php-7.3.0beta2/ext/spl/spl_directory.c#L2314-L2323>
 [2021-07-29 14:56 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2021-07-29 14:56 UTC] cmb@php.net 
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] <https://github.com/php/php-src/blob/php-7.4.22/main/streams/memory.c#L384>
[2] <https://3v4l.org/sX6CK>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Mar 31 20:01:29 2025 UTC