#30924 [Opn]: HTTP POST file upload problem
ID: 30924
User updated by: himself at zhwau dot net
Reported By: himself at zhwau dot net
Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
An update on the problem:
Seems that using copy() to move the file DOES work as expected (ie, as
move_uploaded_file is supposed to work). What move_uploaded_file() did
first time round is move the uploaded file not to the current path
(from where the script is running) but rather to the server root
directory - in my case, being something like C:\Progs\Apache2.
Is this a design feature for this function?
Previous Comments:
[2004-12-01 00:54:49] himself at zhwau dot net
The system the command was run on has the following configuration:
- Athlon XP 2000+ 512MB RAM
- Windows XP SP2
- Apache 2.0.52
- PHP 5.0.2 (running as Apache module, php5_module)
The input form that sends the file via POST is as follows:
FORM enctype=multipart/form-data action=vnos.php method=post
INPUT type=file name=slika size=50
INPUT type=submit value=Poslji
/FORM
The receiving page (vnos.php) contains the following code:
?php
$ime = $_FILES['slika']['name'];
$tmp = $_FILES['slika']['tmp_name'];
if (move_uploaded_file($tmp, $ime)) {
echo 'H2File uploaded!';
}
else {
echo 'H2Error during transfer./H2';
}
?
If you submit the file in the first file, move_uploaded_file in the
second file (vnos.php) returns TRUE, but the file isn't moved. Also,
the vardump on $_FILES does return the appropriate information about
the contents and properties of the file submitted via POST.
Using Firefox, if you reload the page and acknowledge resending the
POSTDATA, then the script executes exactly the same, only this time,
the file gets moved. I haven't tested subsequent reloads, but I'm
assuming the file gets overwritten.
In short - the function 'move_uploaded_file' does NOT move the file on
the first run, but resubmitting the POST data makes the function work
properly.
The temp file directory resides in one of the subdirs on the root of
the webserver, and the webserver has full access to any file or dir in
the document root.
[2004-11-30 21:26:35] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please, provide more info about your system: webserver version, used
SAPI, reproduce code etc.
[2004-11-29 01:29:24] himself at zhwau dot net
Description:
When trying to POST upload a file with the proper FORM tag, including
the proper enctype and all (but without size restriction with
MAX_FILE_SIZE as in manual example), the receiving script defined in
ACTION results in move_uploaded_file() returning TRUE even though the
file wasn't moved at all.
Odd things happen when you try reloading the ACTION target page which
makes Firefox repost the data - the second time around, the PHP script
moves the file, even though it is assigned a different temp file name.
Then everything works fine.
Could this be the result of a write-behind process for the filesystem
which makes move_uploaded_file() return true even if it didn't move the
actual file?
Reproduce code:
---
?php
// The receiving script
$ime = $_FILES['slika']['name'];
if (move_uploaded_file($_FILES['slika']['tmp_name'], $ime)) {
// Here i execute the code responsible for handling the file
}
else {
// Report that the upload failed
}
?
Expected result:
Should execute the 'ELSE' part of the sentence, since the
move_upload_file() should return true in the case of a failed file move
- unless it only detects whether or not the tmp_name file exists.
Actual result:
--
First time around, the move_uploaded_file() returns true (meaning the
temp file exists) but the file isn't moved to $ime (i.e. the same dir
where the script is executed).
If you reload the page (and repost the same data), the tmp_name changes
while all stays the same and the file is successfully moved.
--
Edit this bug report at http://bugs.php.net/?id=30924edit=1
#30924 [Fbk-Opn]: HTTP POST file upload problem
ID: 30924
User updated by: himself at zhwau dot net
Reported By: himself at zhwau dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
The system the command was run on has the following configuration:
- Athlon XP 2000+ 512MB RAM
- Windows XP SP2
- Apache 2.0.52
- PHP 5.0.2 (running as Apache module, php5_module)
The input form that sends the file via POST is as follows:
FORM enctype=multipart/form-data action=vnos.php method=post
INPUT type=file name=slika size=50
INPUT type=submit value=Poslji
/FORM
The receiving page (vnos.php) contains the following code:
?php
$ime = $_FILES['slika']['name'];
$tmp = $_FILES['slika']['tmp_name'];
if (move_uploaded_file($tmp, $ime)) {
echo 'H2File uploaded!';
}
else {
echo 'H2Error during transfer./H2';
}
?
If you submit the file in the first file, move_uploaded_file in the
second file (vnos.php) returns TRUE, but the file isn't moved. Also,
the vardump on $_FILES does return the appropriate information about
the contents and properties of the file submitted via POST.
Using Firefox, if you reload the page and acknowledge resending the
POSTDATA, then the script executes exactly the same, only this time,
the file gets moved. I haven't tested subsequent reloads, but I'm
assuming the file gets overwritten.
In short - the function 'move_uploaded_file' does NOT move the file on
the first run, but resubmitting the POST data makes the function work
properly.
The temp file directory resides in one of the subdirs on the root of
the webserver, and the webserver has full access to any file or dir in
the document root.
Previous Comments:
[2004-11-30 21:26:35] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please, provide more info about your system: webserver version, used
SAPI, reproduce code etc.
[2004-11-29 01:29:24] himself at zhwau dot net
Description:
When trying to POST upload a file with the proper FORM tag, including
the proper enctype and all (but without size restriction with
MAX_FILE_SIZE as in manual example), the receiving script defined in
ACTION results in move_uploaded_file() returning TRUE even though the
file wasn't moved at all.
Odd things happen when you try reloading the ACTION target page which
makes Firefox repost the data - the second time around, the PHP script
moves the file, even though it is assigned a different temp file name.
Then everything works fine.
Could this be the result of a write-behind process for the filesystem
which makes move_uploaded_file() return true even if it didn't move the
actual file?
Reproduce code:
---
?php
// The receiving script
$ime = $_FILES['slika']['name'];
if (move_uploaded_file($_FILES['slika']['tmp_name'], $ime)) {
// Here i execute the code responsible for handling the file
}
else {
// Report that the upload failed
}
?
Expected result:
Should execute the 'ELSE' part of the sentence, since the
move_upload_file() should return true in the case of a failed file move
- unless it only detects whether or not the tmp_name file exists.
Actual result:
--
First time around, the move_uploaded_file() returns true (meaning the
temp file exists) but the file isn't moved to $ime (i.e. the same dir
where the script is executed).
If you reload the page (and repost the same data), the tmp_name changes
while all stays the same and the file is successfully moved.
--
Edit this bug report at http://bugs.php.net/?id=30924edit=1
#30924 [NEW]: HTTP POST file upload problem
From: himself at zhwau dot net
Operating system: Windows XP
PHP version: 5.0.2
PHP Bug Type: Unknown/Other Function
Bug description: HTTP POST file upload problem
Description:
When trying to POST upload a file with the proper FORM tag, including
the proper enctype and all (but without size restriction with
MAX_FILE_SIZE as in manual example), the receiving script defined in
ACTION results in move_uploaded_file() returning TRUE even though the file
wasn't moved at all.
Odd things happen when you try reloading the ACTION target page which
makes Firefox repost the data - the second time around, the PHP script
moves the file, even though it is assigned a different temp file name.
Then everything works fine.
Could this be the result of a write-behind process for the filesystem
which makes move_uploaded_file() return true even if it didn't move the
actual file?
Reproduce code:
---
?php
// The receiving script
$ime = $_FILES['slika']['name'];
if (move_uploaded_file($_FILES['slika']['tmp_name'], $ime)) {
// Here i execute the code responsible for handling the file
}
else {
// Report that the upload failed
}
?
Expected result:
Should execute the 'ELSE' part of the sentence, since the
move_upload_file() should return true in the case of a failed file move -
unless it only detects whether or not the tmp_name file exists.
Actual result:
--
First time around, the move_uploaded_file() returns true (meaning the temp
file exists) but the file isn't moved to $ime (i.e. the same dir where the
script is executed).
If you reload the page (and repost the same data), the tmp_name changes
while all stays the same and the file is successfully moved.
--
Edit bug report at http://bugs.php.net/?id=30924edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30924r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30924r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30924r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30924r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30924r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30924r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30924r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30924r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30924r=support
Expected behavior: http://bugs.php.net/fix.php?id=30924r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30924r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30924r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30924r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30924r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30924r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30924r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30924r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30924r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30924r=mysqlcfg
#30925 [NEW]: HTTP POST file upload problem
From: himself at zhwau dot net
Operating system: Windows XP
PHP version: 5.0.2
PHP Bug Type: Unknown/Other Function
Bug description: HTTP POST file upload problem
Description:
When trying to POST upload a file with the proper FORM tag, including
the proper enctype and all (but without size restriction with
MAX_FILE_SIZE as in manual example), the receiving script defined in
ACTION results in move_uploaded_file() returning TRUE even though the file
wasn't moved at all.
Odd things happen when you try reloading the ACTION target page which
makes Firefox repost the data - the second time around, the PHP script
moves the file, even though it is assigned a different temp file name.
Then everything works fine.
Could this be the result of a write-behind process for the filesystem
which makes move_uploaded_file() return true even if it didn't move the
actual file?
Reproduce code:
---
?php
// The receiving script
$ime = $_FILES['slika']['name'];
if (move_uploaded_file($_FILES['slika']['tmp_name'], $ime)) {
// Here i execute the code responsible for handling the file
}
else {
// Report that the upload failed
}
?
Expected result:
Should execute the 'ELSE' part of the sentence, since the
move_upload_file() should return true in the case of a failed file move -
unless it only detects whether or not the tmp_name file exists.
Actual result:
--
First time around, the move_uploaded_file() returns true (meaning the temp
file exists) but the file isn't moved to $ime (i.e. the same dir where the
script is executed).
If you reload the page (and repost the same data), the tmp_name changes
while all stays the same and the file is successfully moved.
Apache 2.0.52 / PHP 5.0.2 running on WinXP SP2
--
Edit bug report at http://bugs.php.net/?id=30925edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30925r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30925r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30925r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30925r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30925r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30925r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30925r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30925r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30925r=support
Expected behavior: http://bugs.php.net/fix.php?id=30925r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30925r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30925r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30925r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30925r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30925r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30925r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30925r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30925r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30925r=mysqlcfg
