(Illustration by Gaich Muramatsu)
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. JanReceived on 2000-10-06 11:19:04