On 25/07/15 06:07, Pádraig Brady wrote: > 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'.
Another possibility might be that the chmod(1) and stat(2) are racy thus allowing the stat() to succeed? If that was the case then a stat d/s && skip_ ... would avoid the false failure?