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

go to bug id or search bugs for

Bug #64178 move_uploaded_file() sometimes executes a copy followed by a move unnecessarily
Submitted: 2013-02-09 02:20 UTC Modified: 2021-05-31 15:59 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: jbrown at bluedroplet dot com Assigned: cmb (profile)
Status: Wont fix Package: Streams related
PHP Version: 5.4.11 OS: Ubuntu 12.10
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jbrown at bluedroplet dot com
New email:
PHP Version: OS:

 

 [2013-02-09 02:20 UTC] jbrown at bluedroplet dot com 
Description:
------------
move_uploaded_file() executes a copy followed by a move when stream wrapper URIs are used, even the source and destination are on the same file system

See http://drupal.org/node/1395524

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-02-15 23:14 UTC] cataphract@php.net 
You mean copy followed by a delete? In which case, PHP just calls rename(2) and, if that fails, moves on to copy+delete. Apart from the case where the destination is actually a file:// URL, I don't see any situation where the copy is unnecessary and PHP could detect it. Can you elaborate on that point?
 [2013-02-15 23:14 UTC] cataphract@php.net
-Status: Open +Status: Feedback
 [2013-02-17 00:22 UTC] jbrown at bluedroplet dot com 
I used to run a transcoding server and it would fall over if a 1GB file was uploaded. Pre-resolving the private:// URI before passing it to move_uploaded_file() would prevent this from happening as it would issue a rename instead of a copy followed by a delete.

In general, when moving a file between stream wrappers it makes sense to attempt to resolve them both. If they do both resolve then an rename can be issued instead of a copy followed by a delete. If source and destination are on the same filesystem then this will be extremely cheap.
 [2013-02-17 00:22 UTC] jbrown at bluedroplet dot com
-Status: Feedback +Status: Open
 [2021-05-31 15:59 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-05-31 15:59 UTC] cmb@php.net 
This is not particularly related to move_uploaded_file(), but
rather a general restriction of rename() which is not supported
across wrapper types.  To resolve this on the php-src level,
wrappers would need to know about other wrappers.  I don't think
this will be implemented.

If you still think this situation should be improved, please
pursue the RFC process[1].

[1] <https://wiki.php.net/rfc/howto>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Dec 04 07:01:31 2024 UTC