On Fri, Oct 06, 2000 at 04:42:19PM +0200, Roland Mainz wrote:
> Jan Harkes wrote:
> 
> > > Can someone verify that "find ." doesn't work on a CODA filesystem ?
> > >
> > > I'll get
> > > -- snip --
> > > % find .
> > > find: cannot open .: Error 0
> > > -- snip --
> > > on my Solaris 7 SPARC box... ;-(
> > 
> > Does "find . -noleaf" work?
> 
> Uhm... there is no -noleaf option in Solaris (2.7) /usr/bin/find... ;-(
> 
> What does this option do ?

It disables a GNU find optimization.

Volume mount points in Coda are represented as symbolic links. So the
directory link count doesn't account for mounted volumes. GNU find has
this optimization that once it has seen "parent link count - 2"
directories, the rest of the directory entries are assumed to be files,
and find can therefore avoid a couple of stat(2) calls.

I believe I once read that there is some magic linkcount that
automatically turns off this optimization (nlink == 1 probably). I
probably have to look at the find sourcecode to discover this. As I've
not seen any reference to this in any POSIX or SuS references.

I don't really know much about the Solaris kernel module implementation,
but in this case it could also be that find tries to avoid using
readdir syscalls, but rather tries to read or mmap the directory for
faster access, maybe truss or strace can show which syscall returns the
error.

Jan