"Richard L. Hamilton" <rlhamil at smart.net> wrote:
> > 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.
The man page is unfortunately wrong as it tries to imply that filesystems that
don't work with GNU find are non-POSIX compliant.
In fact, GNU find is non-POSIX compliant. It by default fails on filesystems
that are 100% POSIX compliant but do not implement a specific bahavior that
is expexted by GNU find but not granted by POSIX.
sfind implements the speed up _only_ on filesystems that are known to
implement st_nlink == num-subdirs + 2 ("ufs" and "zfs"). This behavior is
however present on more filesystems than "ufs" and "zfs" and for this reason,
sfind (being 100% POSIX compliant) is working correctly, but _not_ as fast
as possible on all possible filesystems. Examples where sfind could speed up
but currently can't are: "lofs" or "nfs" with underlying "ufs" or "zfs" and
"ISO-9660+Rock-Ridge" if the filesystem has been created by a recent mkisofs.
The Solaris "hsfs" implementation includes a test for "created by a recent
enought mkisofs".
For this reason, I proposed to implement a related pathconf() call to allow to
test whether a specific filesystem implements st_nlink == num-subdirs + 2 in a
related POSIX mailing list discussion a few years ago.
Let us see whether this is _really_ an Architecture review mailing list and we
are able to decide that Solaris has to implement this pathconf() call soon....
If Solaris implements this call, POSIX will be able to include it in a future
version.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
