[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in error when "mv" when you don't have access to source file
From: |
Philip Rowlands |
Subject: |
Re: Bug in error when "mv" when you don't have access to source file |
Date: |
Mon, 26 Nov 2007 13:31:21 +0000 (GMT) |
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