[bug #20970] Trailing slash on directory arguments breaks -name
Update of bug #20970 (project findutils): Status: Confirmed = Fixed Assigned to: ericb = jay ___ Reply to this item at: http://savannah.gnu.org/bugs/?20970 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug in error when mv when you don't have access to source file
This is a copy of the sequence of commands with which to reproduce this problem. [EMAIL PROTECTED] admin_scripts $ sudo mkdir /tmp/mvbug [EMAIL PROTECTED] admin_scripts $ sudo touch /tmp/mvbug/file [EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file /tmp/file1 mv: cannot move `/tmp/mvbug/file' to `/tmp/file1': Permission denied [EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file . mv: cannot remove `/tmp/mvbug/file': Not a directory [EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file ./ mv: cannot remove `/tmp/mvbug/file': Not a directory Basically what it is, when you don't have write access or ownership of the source file, you can't move the file when your target directory is . or ./, but instead of displaying Permission denied it displays Not a directory. My version of coreutils: 6.7-r1 Distro: Gentoo 2006.1 mv --version output: mv (GNU coreutils) 6.7 /pro/version: Linux version 2.6.20-gentoo-r6-quintin ([EMAIL PROTECTED]) (gcc version 4.1.1(Gentoo 4.1.1-r3)) #5 SMP Tue Sep 18 15:17:40 SAST 2007 -- Quintin Beukes Tel: 074 103 7355 Fax: 0866 600 700 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in error when mv when you don't have access to source file
On Mon, 26 Nov 2007, Quintin Beukes wrote:
This is a copy of the sequence of commands with which to reproduce this
problem.
[EMAIL PROTECTED] admin_scripts $ sudo mkdir /tmp/mvbug
[EMAIL PROTECTED] admin_scripts $ sudo touch /tmp/mvbug/file
[EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file /tmp/file1
mv: cannot move `/tmp/mvbug/file' to `/tmp/file1': Permission denied
[EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file .
mv: cannot remove `/tmp/mvbug/file': Not a directory
[EMAIL PROTECTED] 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
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in error when mv when you don't have access to source file
Quintin Beukes [EMAIL PROTECTED] wrote: ... Basically what it is, when you don't have write access or ownership of the source file, you can't move the file when your target directory is . or ./, but instead of displaying Permission denied it displays Not a directory. Thanks for the report. That's been fixed in snapshots only since 2007-10-05. Here's the corresponding NEWS entry: A cross-partition mv /etc/passwd ~ (by non-root) now prints a reasonable diagnostic. Before, it would print this: mv: cannot remove `/etc/passwd': Not a directory. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du: fts and vfat
Jim Meyering wrote: Yes, it's expected, whenever you use a file system with imperfect-by-definition inode emulation. AFAIR, the fat driver uses the starting cluster of the file as the inode number, so unless you defrag or something, it shouldn't change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du: fts and vfat
Phillip Susi [EMAIL PROTECTED] wrote: Jim Meyering wrote: Yes, it's expected, whenever you use a file system with imperfect-by-definition inode emulation. AFAIR, the fat driver uses the starting cluster of the file as the inode number, so unless you defrag or something, it shouldn't change. Sorry, but no. If only it were so easy. The kernel maintains a limited-space cache for FAT inodes, so the inode of . at the beginning of a traversal will not be the same as the inode reported for that same directory after du/fts has traversed a tree that's large enough. As I said, use a newer version of coreutils, and not in chdir-mode, and du works a lot better with FAT. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du: fts and vfat
Al Viro [EMAIL PROTECTED] wrote: The real issue is that starting cluster won't work at all for empty files. IOW, ftruncate() would change st_ino; no-go for all kinds of obvious reasons. Now, one _could_ play games with separating inode numbers of directories and non-directories, but that causes too much PITA. What we have is a guaranteed st_ino doesn't change for the lifetime of in-core inode, without any promise of persistence beyond that. Since way back - at least '99, IIRC. Here (in gnulib's fts.c), inodes are only ever compared for directories, so treating directories specially would help. While FAT may not be worth even a small PITA, some other types of file systems with similar limitations might be, e.g., FUSE-based ones. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du: fts and vfat
On Mon, Nov 26, 2007 at 09:49:14PM +0100, Jim Meyering wrote: Phillip Susi [EMAIL PROTECTED] wrote: Jim Meyering wrote: Yes, it's expected, whenever you use a file system with imperfect-by-definition inode emulation. AFAIR, the fat driver uses the starting cluster of the file as the inode number, so unless you defrag or something, it shouldn't change. Sorry, but no. If only it were so easy. The kernel maintains a limited-space cache for FAT inodes, so the inode of . at the beginning of a traversal will not be the same as the inode reported for that same directory after du/fts has traversed a tree that's large enough. The real issue is that starting cluster won't work at all for empty files. IOW, ftruncate() would change st_ino; no-go for all kinds of obvious reasons. Now, one _could_ play games with separating inode numbers of directories and non-directories, but that causes too much PITA. What we have is a guaranteed st_ino doesn't change for the lifetime of in-core inode, without any promise of persistence beyond that. Since way back - at least '99, IIRC. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
