[Toybox] [PATCH] find.test: fix test expectation for BSD libcs.

[Rob Landley]

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