Re: Bug in error when "mv" when you don't have access to source file

[Philip Rowlands]

On Mon, 26 Nov 2007, Quintin Beukes wrote:

> This is a copy of the sequence of commands with which to reproduce this
> problem.
> --------------------------------------------
> address@hidden admin_scripts $ sudo mkdir /tmp/mvbug
> address@hidden admin_scripts $ sudo touch /tmp/mvbug/file
> address@hidden admin_scripts $ mv /tmp/mvbug/file /tmp/file1
> mv: cannot move `/tmp/mvbug/file' to `/tmp/file1': Permission denied
> address@hidden admin_scripts $ mv /tmp/mvbug/file .
> mv: cannot remove `/tmp/mvbug/file': Not a directory
> address@hidden admin_scripts $ mv /tmp/mvbug/file ./
> mv: cannot remove `/tmp/mvbug/file': Not a directory
> --------------------------------------------

You don't specify whether "." is on a different filesystem; this affects 
whether mv can use a rename(2) syscall, or has to copy and delete. I 
suspect "." is not on the same filesystem as /tmp, in which case the 
strace output looks like this:
(boring lines hidden)

rename("/tmp/mvbug/file", "./file")     = -1 EXDEV (Invalid cross-device link)
unlink("./file")                        = 0
open("/tmp/mvbug/file", O_RDONLY|O_LARGEFILE) = 3
open("./file", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
fchown32(4, 0, 0)                       = -1 EPERM (Operation not permitted)
fchmod(4, 0100644)                      = 0
close(4)                                = 0
close(3)                                = 0
unlinkat(AT_FDCWD, "/tmp/mvbug/file", 0) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/tmp/mvbug/file", 
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)                                = 0
unlinkat(AT_FDCWD, "/tmp/mvbug/file", AT_REMOVEDIR) = -1 EACCES (Permission 
denied)
write(2, "mv: ", 4mv: )                     = 4
write(2, "cannot remove `/tmp/mvbug/file\'", 31) = 31
write(2, ": Not a directory", 17: Not a directory)       = 17
write(2, "\n", 1)


I agree that mv's diagnostic message doesn't correspond to the syscall 
return value. Will have to dig around the source and see if I can spot 
what causes this.


Cheers,
Phil