> Darren J Moffat <Darren.Moffat at Sun.COM> wrote: > > > GNU find should be integrated as it is upstream > except for any changes > > necessary to make it compile and run on Solaris. > If there are generic > bugs/issues like the one you described it isn't upto > *this* project team > to fix them. That is for the upstream community to > fix. > Will you add a note to the GNU find man page to > inform about the bug? > > J?rg
The man page sort of mentions it (following cut/pasted from case materials, so troff markup is still visible): .IP "\-noleaf" Do not optimize by assuming that directories contain 2 fewer subdirectories than their hard link count. This option is needed when searching filesystems that do not follow the Unix directory-link convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount points. Each directory on a normal Unix filesystem has at least 2 hard links: its name and its `.' entry. Additionally, its subdirectories (if any) each have a `..' entry linked to that directory. When .B find is examining a directory, after it has statted 2 fewer subdirectories than the directory's link count, it knows that the rest of the entries in the directory are non-directories (`leaf' files in the directory tree). If only the files' names need to be examined, there is no need to stat them; this gives a significant increase in search speed. You may not consider that sufficient warning that their behavior may be incompatible with other implementations unless -noleaf is used. I may even agree. Whether the project team or anyone else agrees that this needs to be either fixed or highlighted more in the man page, that's another story. This message posted from opensolaris.org
