>Number:         12902
>Category:       bin
>Synopsis:       find(1) gives spurious "No such file or directory" errors when fdesc present
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 10 14:30:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Anne Bennett
>Release:        1.5
>Organization:
Concordia University
>Environment:
NetBSD eridani.concordia.ca 1.5 NetBSD 1.5 (ERIDANI) #1: Tue Mar 20 15:48:34 EST 2001     anne@eridani.concordia.ca:/big/sources/usr/src/sys/arch/i386/compile/ERIDANI i386

>Description:
Under some circumstances, the "find" command reports "No such file
or directory" for directories which do exist.  While I can't find
a pattern to why some directories are thus misreported while most
are not, I can say that (1) the behaviour is consistent, in that I
always see the *same* list of directories reported, (2) the behaviour
does not seem to depend on the amount of data processed, in that in
my tests, I saw the same errors even when I pruned out most of the
directories being searched, (3) the problem is related to trying to
process an fdesc filesystem -- it is after the fdesc filesystem is
traversed, and an error reported for /dev/fd/4, that the other errors
are reported.  If I prune out /dev, or if I prune "fstype fdesc", the
problem goes away.  Perhaps some error condition is not being
cleared properly?
>How-To-Repeat:
I found the problem while installing COPS (yes, I know that NetBSD
1.5 now has its own setuid file checker), so here's the code snippet
that causes the problem on my system:

-----
#!/bin/sh

TEMPCUR=/tmp/testfind/out.$$
TEMPERR=/tmp/testfind/err.$$

/usr/bin/find / \
   \(        \( -path /usr -prune         \)    \
          -o \( -path /big -prune         \) \) -o \
  -type f \( -perm -4000 -o -perm -2000 \) \
  -exec /bin/ls -ldag {} \; 2> $TEMPERR > $TEMPCUR

-------

Make sure you test on a system which uses the fdesc filesystem, i.e.
with this in fstab:

  /dev      /dev    fdesc   ro,union  0 0

To show that the problem is removed when the fdesc files are not
traversed, add one of these to the "find" statement above:

  -fstype fdesc -a -prune -o
or
  -path /usr -prune
  

   
>Fix:
Not known, sorry.  :-(
>Release-Note:
>Audit-Trail:
>Unformatted: