ID: 30924
Comment by: alex at mintpixels dot com
Reported By: himself at zhwau dot net
Status: No Feedback
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
oops - hit tab then space, so it submitted before I was done:
if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location))
{
echo "Success";
} else {
echo "Failure";
}
This prints the warning message, then "Success" when executed.
Previous Comments:
------------------------------------------------------------------------
[2006-12-01 04:27:36] alex at mintpixels dot com
I have created a simple test case:
<html><body><form method='POST' action='testUpload.php'
accept-charset="UTF-8" enctype="multipart/form-data">
<input type='hidden' name='MAX_FILE_SIZE' value="300000000"/>
<input type='file' name='worksheet_new'/><br/>
<input type='submit' value='submit'/>
</body>
</html>
posts to
<?php
$location="<path to my directory>";
if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location))
{
}
------------------------------------------------------------------------
[2006-12-01 04:17:49] alex at mintpixels dot com
I can also confirm that this is a problem in 5.2.0.
I am using move_uploaded_file to move a file from /tmp/<tmpname> to
<docroot>/worksheets/3.jpg
On the initial upload, I get no openbase_dir message, and the file
writes successfully and the function returns true (as I expected).
On the second upload to the file (where the file exists already), I get
an openbase_dir error message in the error log and the file does not
write successfully, but the function still returns a true value anyway
(not as expected).
I have also witnessed a case where I get no openbase_dir message and
the new file writes successfully.
I verified this by checking the file size had changed between requests
(as I had uploaded a different file), which it had. But I am now
unable to reproduce that problem.
In all cases however the function is returning true.
I am using PHP 5.2.0 on Apache 2.0.59 on Linux 2.6.9-42.0.2.ELsmp i686
athlon i386 GNU/Linux.
The permissions of the directory/file are clearly correct because the
first upload is writing correctly. I have also verified the
permissions independently by doing
$h=fopen("$docroot/worksheets/3.jpg"); fwrite($h,"test"); fclose($h);
The file is created and contains the line as expected.
--------------------------------------------------------
In line with the guidelines, I have downloaded the latest build from
CVS, and the following behaviour has changed.
I now get an open_basedir warning message on the initial upload in the
log, but the file is written anyway, and the function still returns
true.
the same behaviour persists with the second upload.
------------------------------------------------------------------------
[2005-02-19 01:00:21] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2005-02-11 23:20:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
------------------------------------------------------------------------
[2004-12-27 09:33:38] himself at zhwau dot net
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?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30924
--
Edit this bug report at http://bugs.php.net/?id=30924&edit=1
