#45283 [Opn]: extract($_FILES) result unpredictable
ID: 45283
Updated by: [EMAIL PROTECTED]
Reported By: php at info-svc dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.6
New Comment:
Results of extract() shouldn't depend on register_globals.
Previous Comments:
[2008-07-02 12:26:50] [EMAIL PROTECTED]
It's documentation issue. Plus you really should NOT be using
register_globals=On. And using extract() on $_FILES...well..that's very
flaky idea to begin with. Just don't do it. :)
[2008-06-19 04:59:15] php at info-svc dot com
I confirmed this behavior with PHP 5.2.6 running on IIS and Windows
2003 SP2.
Test case output with register_globals Off
array(5) {
["name"]=>
string(14) "samplefile.txt"
["type"]=>
string(10) "text/plain"
["tmp_name"]=>
string(25) "C:\WINDOWS\Temp\php57.tmp"
["error"]=>
int(0)
["size"]=>
int(459)
}
string(25) "C:\WINDOWS\Temp\php57.tmp"
Test case output with register_globals On
string(25) "C:\WINDOWS\Temp\php58.tmp"
string(1) "C"
So I'm convinced that register_globals is involved here. There is
something horribly wrong with this feature or its documentation.
[2008-06-16 18:09:31] php at info-svc dot com
Adding to the confusion, I thought perhaps the unexpected behavior
could be caused by the register_globals configuration. However,
according to documentation ...
http://www.php.net/manual/en/faq.misc.php#faq.misc.registerglobals
... extract($_FILES, EXTR_SKIP); is the correct way to emulate
register_globals On. I dumped all of the other superglobals and
confirmed the only one containing a 'themefile' index was $_FILES. Both
var_dump($_POST); and var_dump($_GET); returned "array(0) {}"
[2008-06-16 17:39:59] php at info-svc dot com
Note about the "Reproduce code", for best results use
[2008-06-16 17:20:28] php at info-svc dot com
Description:
After receiving reports of a broken feature, the problem was traced to
extract($_FILES) producing different results on different servers.
A server running PHP 5.2.5 gave the expected result where
$variable['tmp_name'] contained the uploaded file path. A server
running PHP 5.2.3 gave the unexpected result where $variable['tmp_name']
always dumped as string(1) "/"
The workaround is to use $_FILES['tmp_name'] in which case both servers
gave the expected result.
I am stumped as to whether this is caused by a bug that was fixed
between versions or some configuration issue I am not aware of?
Robert Chapin
Chapin Information Services, Inc.
Reproduce code:
---
Expected result:
array(5) {
["name"]=>
string(20) "samplefile.txt"
["type"]=>
string(24) "application/octet-stream"
["tmp_name"]=>
string(18) "/var/tmp/phpSJkwr0"
["error"]=>
int(0)
["size"]=>
int(379)
}
string(18) "/var/tmp/phpSJkwr0"
Actual result:
--
string(14) "/tmp/phpZOtyB7"
string(1) "/"
--
Edit this bug report at http://bugs.php.net/?id=45283&edit=1
#45283 [Opn]: extract($_FILES) result unpredictable
ID: 45283
User updated by: php at info-svc dot com
Reported By: php at info-svc dot com
Status: Open
Bug Type: Unknown/Other Function
-Operating System: Linux
+Operating System: Linux and Windows servers
PHP Version: 5.2.6
New Comment:
I confirmed this behavior with PHP 5.2.6 running on IIS and Windows
2003 SP2.
Test case output with register_globals Off
array(5) {
["name"]=>
string(14) "samplefile.txt"
["type"]=>
string(10) "text/plain"
["tmp_name"]=>
string(25) "C:\WINDOWS\Temp\php57.tmp"
["error"]=>
int(0)
["size"]=>
int(459)
}
string(25) "C:\WINDOWS\Temp\php57.tmp"
Test case output with register_globals On
string(25) "C:\WINDOWS\Temp\php58.tmp"
string(1) "C"
So I'm convinced that register_globals is involved here. There is
something horribly wrong with this feature or its documentation.
Previous Comments:
[2008-06-16 18:09:31] php at info-svc dot com
Adding to the confusion, I thought perhaps the unexpected behavior
could be caused by the register_globals configuration. However,
according to documentation ...
http://www.php.net/manual/en/faq.misc.php#faq.misc.registerglobals
... extract($_FILES, EXTR_SKIP); is the correct way to emulate
register_globals On. I dumped all of the other superglobals and
confirmed the only one containing a 'themefile' index was $_FILES. Both
var_dump($_POST); and var_dump($_GET); returned "array(0) {}"
[2008-06-16 17:39:59] php at info-svc dot com
Note about the "Reproduce code", for best results use
[2008-06-16 17:20:28] php at info-svc dot com
Description:
After receiving reports of a broken feature, the problem was traced to
extract($_FILES) producing different results on different servers.
A server running PHP 5.2.5 gave the expected result where
$variable['tmp_name'] contained the uploaded file path. A server
running PHP 5.2.3 gave the unexpected result where $variable['tmp_name']
always dumped as string(1) "/"
The workaround is to use $_FILES['tmp_name'] in which case both servers
gave the expected result.
I am stumped as to whether this is caused by a bug that was fixed
between versions or some configuration issue I am not aware of?
Robert Chapin
Chapin Information Services, Inc.
Reproduce code:
---
Expected result:
array(5) {
["name"]=>
string(20) "samplefile.txt"
["type"]=>
string(24) "application/octet-stream"
["tmp_name"]=>
string(18) "/var/tmp/phpSJkwr0"
["error"]=>
int(0)
["size"]=>
int(379)
}
string(18) "/var/tmp/phpSJkwr0"
Actual result:
--
string(14) "/tmp/phpZOtyB7"
string(1) "/"
--
Edit this bug report at http://bugs.php.net/?id=45283&edit=1
