On 24/07/15 22:46, Assaf Gordon wrote: > Hello, > > checking coreutils 8.24, running on NFS, the test 'ls/stat-failed' fails (log > attached). > > If I understand correctly, > The test creates a symlink to a directory then removes execute permissions: > mkdir d > ln -s / d/s > chmod 600 d > > Then tries to dereference it: > $ ls -Log d > ls: cannot access d/s: Permission denied > total 0 > d????????? ? ? ? s > > The test expect 's' to have 'l' type, on my system it is 'd'. > > The attached patch avoids the failure, though I don't know if this is correct > or not (perhaps this failure should not be avoided?). > > The system is: > $ uname -a > Linux XXX 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux > $ gcc --version > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) > > The file system is NFS.
Interesting. Is the NFS server RHEL6 too? With normal perms on 'd': On ext4 I get ^d With syscalls being: getdents(3, /* 3 entries */, 32768) = 72 stat("d/s", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 With -x perms on 'd': On nfsv4 here I get ^? On ext4 I get ^l With syscalls being: getdents(3, /* 3 entries */, 32768) = 72 stat("d/s", 0x7f634b9594a0) = -1 EACCES (Permission denied) So it seems you're getting next->d_type==DR_DIR in that case? That would be wrong, but a system issue rather than a problem in ls I think. The test adjustment looks OK but would benefit from a comment stating the first letter represents d_type and that on buggy systems may be 'd'. thanks! Pádraig