php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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: Tue Mar 19 04:01:31 2024 UTC