On 8/26/19 11:20 PM, enh wrote: > this comment had me worried: > > "Tweak DIRTREE_STATLESS so it returns zero stat for any error (I'm testing > that dev, ino, and blksize are all zero), and fill in file type from > readdir()" > > and indeed, this breaks one of the find(1) tests i added. (and is how > we reopened this conversation about ls(1) --- the difference between > find which only ignores ENOENT and ls which ignores more.)
Except the error I'm getting on my dir test isn't ENOENT, it's "permission denied" which is EACCES. So which errors should it ignore? I changed it because only a couple things are using DIRTREE_STATLESS. Sigh, I don't have test cases for this. Which specific error cases are what here? According to man 2 stat, we got: EACCES (this), EBADF (pilot error), EFAULT (pilot error), ELOOP (TODO: test), ENAMETOOLONG (equivalent to ENOENT, sort of ECANTENT), ENOMEM(pilot error), ENOTDIR (ECANTENT), EOVERFLOW (doesn't apply to us), EBADF (pilot error), EINVAL (pilot error), and a different ENOTDIR because of dirfd (pilot error except maybe the nocwd "." has been deleted case?). You know, what it sounds like is DIRTREE_STATLESS needs to stick errno in one of the stat fields so the caller can check it when they care. I'm currently using st_dev, st_ino, and st_blksize are all zero (which should never happen; st_blksize should never be zero but I don't trust it and only one device/ino in the system can ever be 0/0 and I think it would be the first file in initramfs?) Ok, EACCES, ELOOP, ENOENT, ENAMETOOLONG, and sometimes ENOTDIR are _not_ pilot error. And the test you added was that ELOOP should NOT get caught. Hmmm... $ ls -l loop/ ls: cannot access 'loop/': Too many levels of symbolic links $ ./toybox ls -l loop/ -????????? ? ? ? ? ? loop/ It looks like ELOOP should always get caught as an error? $ find dirtest dirtest dirtest/three dirtest/dev dirtest/one dirtest/slink find: ‘dirtest/subdir’: Permission denied dirtest/subdir dirtest/two $ ./toybox find dirtest dirtest dirtest/three dirtest/dev dirtest/one dirtest/slink dirtest/two And that's a behavior difference too. (It complains _and_ shows it, mine's doing neither.) $ ls $(tr \\0 x < /dev/zero | head -c 260) ls: cannot access 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx': File name too long Not filtered out... Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net