move_uploaded_file

(PHP 4 >= 4.0.3, PHP 5, PHP 7)

move_uploaded_file — Moves an uploaded file to a new location

Description

boolmove_uploaded_file
( string$filename
, string$destination
)

This function checks to ensure that the file designated by
filename is a valid upload file (meaning
that it was uploaded via PHP's HTTP POST upload mechanism). If
the file is valid, it will be moved to the filename given by
destination.

This sort of check is especially important if there is any chance
that anything done with uploaded files could reveal their
contents to the user, or even to other users on the same
system.

Parameters

filename

The filename of the uploaded file.

destination

The destination of the moved file.

Return Values

Returns TRUE on success.

If filename is not a valid upload file,
then no action will occur, and
move_uploaded_file() will return
FALSE.

If filename is a valid upload file, but
cannot be moved for some reason, no action will occur, and
move_uploaded_file() will return
FALSE. Additionally, a warning will be issued.

Notes

Note:

move_uploaded_file() is both safe mode
and open_basedir
aware. However, restrictions are placed only on the
destination path as to allow the moving
of uploaded files in which filename may conflict
with such restrictions. move_uploaded_file() ensures
the safety of this operation by allowing only those files uploaded
through PHP to be moved.

For those using PHP on Windows and IIS, you SHOULD set the "upload_tmp_dir" value in php.ini to some directory around where your websites directory is, create that directory, and then set the same permissions on it that you have set for your websites directory. Otherwise, when you upload a file and it goes into C:\WINDOWS\Temp, then you move it to your website directory, its permissions will NOT be set correctly. This will cause you problems if you then want to manipulate that file with something like ImageMagick's convert utility.

That function will work fine for files with a 3-character file extension. However, it is worth noting that there are valid, registered file extensions that are longer than 3 characters. For example, a JPEG file can be denoted by *.jpg (and others), but it can also have *.jpeg as a valid extension. Check out http://www.filext.com/ for a good reference of file extensions.

The best bet to me would be parsing the uploaded file's name ($_FILES['uploadedfile']['name']) based on the presence of dots. Another wrench in the gears: a file can have dots in the filename. That's easy enough to handle -- just explode() the file name and hope that the last element in the array it gives you is the file extension (you can always validate it if you're so inclined). Then just piece it together in a string accordingly by stepping through the array (don't forget to add those dots back to where they were!), appending a guaranteed unique string of characters (or enumerate it like you were doing, keeping track via a loop), and finally tacking on the file extension.

You may have other mechanisms for verifying a file's extension, such as a preg_match on the whole name, using something like "/\\.(gif|jpg|jpeg|png|bmp)$/i" (more can, of course, be added if you so desire) for the most common types of images found on the web.

For blindly guaranteeing an uploaded file will be uniquely named, this seems like a fantastic way to go. Enjoy!

Just a helpful comment. If you have open_basedir set then you must set upload_tmp_dir to somewhere within the open_basedir. Otherwise the file upload will be denied. move_uploaded_file might be open_basedir aware, but the rest of the upload process isn't.

One more thing I want to mention about the post_max_size setting in php.ini that nobody else has mentioned.If you try to upload a file larger than the post_max_size value (or multi files), the page will only refresh itself and no errors are thrown. It took me a while to figure the reason out.

It seems that move_uploaded_file use the GROUP permissions of the parent directory of the tmp file location, whereas a simple "copy" uses the group of the apache process. This could create a security nighmare if your tmp file location is owned by root:wheel

I have looked at a lot of the file upload code listed below and other php documentation and have developed hopefully a robust single file upload routine. I will later update with a multi file upload. I have modestly tested the code.

Make sure your system has the appropriate file loading limits. This caused a lot of headeaches trying to figure out why some files loaded and some did not. In my case I have an .htaccess file in the root of the web site with:

php_value post_max_size 16M
php_value upload_max_filesize 6M

You may also need to extend the execution time depending upon the amount of data being transferred.

(sorry if spacing of code is a little off. it was hard to make the note editor like the code style.)

If you have a directory in a *nix environment where you store all of your file uploads and your php script only seems to work when permissions for that directory are set to 777, here's how to fix it so that you can have the security benefits of 755 while still allowing your php scripts to work, including the move_uploaded_file().

through shell access, navigate to the directory that contains your uploads folder and run the following 2 commands:chown -R nobody uploaddirchmod -R 755 uploaddir

Replace 'uploaddir' with the name of your uploads directory. The first command changes the owner of the directory and files to 'nobody' which is what php operates under. The second changes the folder and files to only allow user access to writing. This is much more secure.

Hopefully this will help someone out there who had the same problem as me.

I have for a couple of years been stymed to understand how to effectively load images (of more than 2MB) and then create thumbnails. My note below on general file uploading was an early hint of some of the system default limitations and I have recently discovered the final limit I offer this as an example of the various missing pieces of information to successfully load images of more than 2MB and then create thumbnails. This particular example assumes a picture of a user is being uploaded and because of browser caching needs a unique number at the end to make the browser load a new picture for review at the time of upload. The overall calling program I am using is a Flex based application which calls this php file to upload user thumbnails.

An extension only does not really tell you what type of file it really is. I can easily rename a .jpg file to a .zip file and make the server think it is a ZIP file with webmaster kobrasrealm's code.

A better way is to use the Linux utility "file" to determine the file type. Although I'm aware that some users might use Windows on their webservers, I thought it's worth mentioning the utility here. Using the backtick operators and preg_matches on the output, you can easily determine the file type safely, and fix the extension when necessary.

If you're dealing with files uploaded through some external FTP source and need to move them to a final destination, searching php.net for "mv" or "move" won't get you what you want. You want the rename() function.

A note for PHP on Windows IIS platform:PHP does obviously not like directory traversing among partitions, so if you set upload_tmp_dir to be on different partition as php-cgi.exe or php.exe is, upload_tmp_dir will NOT be accessible for file uploads! You will get ERROR 6 on any attempt to upload file, and file size will be 0.Resolution is to have upload_tmp_dir set to a path under PHP install folder....and make sure this folder (and also session_save_path folder) has at least read/write permissions granted to AppPool owner (usually NETWORK SERVICE) and IIS web user (by default IUSR_).

If you find that large files do not upload in PHP even though you've changed the max_upload_size , this is because you need to change the max memory size varible too. The entire file is loaded into memory before it is saved to disk.

move_uploaded_file (on my setup) always makes files 0600 ("rw- --- ---") and owned by the user running the webserver (owner AND group).Even though the directory has a sticky bit set to the group permissions!I couldn't find any settings to change this via php.ini or even using "umask()".

I want my regular user on the server to be able to "tar cjf" the directory .. which would fail on files totally owned by the webserver-process-user;the "copy(from, to)" function obeys the sticky-bit though!

When uploading a file with a very long filename, for example 255 characters, move_uploaded_file fails. The longest file I've succesfully uploaded has a 247 character filename. So, although you can create a 250 character filename locally the server may not be able to move it.

When you use move_uploaded_file function to upload a file with utf-8 filename to linux system, you probably check your result by browsing to see the file in the target directory so please make sure that your terminal emulator or your samba configuration is set the character encoding to utf-8 otherwise your file will be shown as ?????? (unreadable character).

to separate (for example) images from other file types among the uploaded files you can check the MIME type also (thus making the file extension check unnecessary)

$temp = strpos($_FILES["pic"]["type"], "image");if ($rep===FALSE){ //the strpos function will return a boolean "false" ONLY if the needle string is not found within the haystack echo "is not an image";}else{ echo "is an image";}

Values upload_max_filesize and post_max_size (ie. php.ini values) cannot be modified in runtime with ini_set() function.If you are using Apache web server, use .htaccess files with an IfModule replacing values corresponding to your file size and PHP version:

Re: Florian S. in H. an der E. [.de]'s point about directory stick bits, I got hit by this a bunch since I use groups and dir sticky bits to secure my site, so I wrote this replacement, which others might find useful:

On the Fedora Core 3 Linux distribution, you may get a "failed to open stream: Permission denied in ..." message. I fact changing the permission of the directory will not work (even if you set to 0777). It is because of the new SELinux kernel that allow apache user to write only in /tmp dir (I think). In order to solve the problem you must to disable the SELinux (at least for apache service) to allow the server to write in other directories. To do that, run the system-config-securitylevel app and disable the SE to apache service. Reboot your system and continue your work. Hope it helps!

I had exactly than" tnp at shaman dot co dot uk" : move_uploaded_file() is either asynchronous or uses some kind of virtual filesystem. But you may encounter big problems when trying to access a file just uploaded, especially is you tried to change the name.If you have problems where the uploaded file seems unaccessible, try to use copy() instead.

I am pretty new, and am having upload problems myself, but I think I can help out ffproberen2 at dodgeit dot com with his premission denied errors. I had these two, and I had to change the upload directory, not the tmp_upload_dir or what ever it is called. The move_uploaded_file meathod takes an upload location as the last parameter. I am running a bundled package of Apache, Php, mySQL and so on, and on mine, specifing a directory of '' will upload it into C:\Program Files\xampp\apache (my PC is my experimental server, I will get linux, but got to obtain it and internet cuts off after 196mb so can't download it) even though php file is in C:\Program Files\xampp\htdocs\xampp\jessyexum\upload_client.php.

This is a code that I found and then modified, hope it can help. It dosn't always upload every file type giving me an error #2.

Warning: If you save a md5_file hash in a database to keep record of uploaded files, which is usefull to prevent users from uploading the same file twice, be aware that after using move_uploaded_file the md5_file hash changes! And you are unable to find the corresponding hash and delete it in the database, when a file is deleted.