|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #50676 rename across Volumes throws warning "Operation not permitted"
Submitted: 2010-01-06 10:16 UTC Modified: 2010-09-06 06:05 UTC
From: andreas at heigl dot org Assigned: aharvey (profile)
Status: Closed Package: Documentation problem
PHP Version: 5.3.1 OS: Mac OS X 10.6
Private report: No CVE-ID: None
 [2010-01-06 10:16 UTC] andreas at heigl dot org
When renaming files acros Volumes a warning is triggered that the 
"Operation is not permitted. 
The operation is executed though.

Reproduce code:
- Create two images and mount them (Image1, Image2). 
- Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files.
- Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile)

ini_set ( 'error_reporting', E_ALL );
ini_set ( 'display_errors', true );
rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' );

Expected result:
The file /Volumes/Image1/testfile has been copied to 
/Volumes/Image2/testfile ad the original file has been removed.
No error should be triggered

Actual result:
The file /Volumes/Image1/testfile has been copied to 
/Volumes/Image2/testfile ad the original file has been removed.

Additionally the following error is triggered:
rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not 
permitted in renametest.php on line n


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-11 12:59 UTC] p dot szalko at gmail dot com
The same bug is in PHP 5.2.11 and Mac OS X 10.5
 [2010-01-14 13:56 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

rename() can only work "normally" when operating on the same volume. 

In your case it emulates rename via copy & delete. I would guess since 
it cannot delete file from the original volume, it gives you an error 
 [2010-01-14 14:45 UTC] andreas at heigl dot org
I understand, that rename can only operate on the same volume (like the move-command). But unlike in windows on a Mac (as on any other UNIX-like environment) volumes can be mount anywhere in the folder-hirachy, so that it is rather difficult to check whether source and target of the rename are on the same volume or not.

And as I pointed out in the original bug-report, the source-file actually is deleted, so there is no need for the error message.
 [2010-01-14 15:10 UTC]
Volumes can be mounted everywhere on windows as well. That does not change the fact that they are a different volume. Please read the underlying documentations for rename and how it works, that may help to understand the limitation.
 [2010-01-14 15:21 UTC]
The warnings may also be coming from the chown() and chmod() calls that occur between the copy and unlink when the rename call has to be faked across partitions -- there's no way of distinguishing them, since the warnings in php_plain_files_rename() just wrap strerror().

I wonder if this might be worth morphing into a doc bug: the rename manual page currently says that, as of 4.3.3, "rename() is now able to rename files across partitions on *nix based systems", which does seem to be overstating things a little. Something along the lines of "rename() may be able to rename files across partitions on *nix based systems, provided the appropriate permissions are held. Warnings may be thrown if the destination filesystem doesn't permit chown() or chmod() calls to be made on files." might be better.
 [2010-09-03 09:19 UTC] sta at netimage dot dk
I would like to second the suggestion of about making this a Documentation issue. I just spend 2 ours trying to figure out why rename() started spitting out warnings and still returned true.

It could be something like
		<b class="note">Note</b>:
		<span class="simpara">
If $oldname and $newname are on different partitions (on *nix based systems) the function might emit a warning "Warning: rename(oldfil,newfile): Operation not permitted" and still succeed. The reason is that internally the rename is done by copying the file, and attempting chown() and chmod() on the new file - and these operations can fail.

FreeBSD, Apache 2.2, PHP 5.3.3.

Thanks for all the good work.

/Søren Thing
 [2010-09-03 20:51 UTC]
-Status: Bogus +Status: To be documented -Assigned To: +Assigned To: aharvey
 [2010-09-03 20:51 UTC]
See your own comment :-)
 [2010-09-06 06:05 UTC]
Automatic comment from SVN on behalf of aharvey
Log: Fix doc bug #50676 (rename across Volumes throws warning &quot;Operation not
 [2010-09-06 06:05 UTC]
-Status: To be documented +Status: Closed -Type: Bug +Type: Documentation Problem -Package: Filesystem function related +Package: Documentation problem
 [2010-09-06 06:05 UTC]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Committed a slight variation on what I originally proposed, mostly to note that FAT filesystems are the most likely culprits here.
 [2013-10-30 13:59 UTC] jorgex0 dot o at gmail dot com
This isn't documented, for what I see. Am I right?
 [2015-07-02 15:34 UTC] ben at indietorrent dot org

No, you are not correct. The documentation has indeed been updated. From the Changelog section at :

4.3.3	rename() may now be able to rename files across partitions on *nix based systems, provided the appropriate permissions are held. Warnings may be generated if the destination filesystem doesn't permit chown() or chmod() system calls to be made on files — for example, if the destination filesystem is a FAT filesystem.
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 18:01:28 2019 UTC