I'm a bit late coming to this thread, sorry. The "oldfind" (i.e.
not-fts) implementation of find iterates over a directory like this:
while (1)
{
const char *namep;
const struct dirent *dp;
/* We reset errno here to distinguish between
end-of-directory and an error */
errno = 0;
dp = readdir (dirp);
if (NULL == dp)
{
if (errno)
{
/* an error occurred, but we are not yet at the end
of the directory stream. */
error (0, errno, "%s", safely_quote_err_filename (0,
pathname));
continue;
}
else
{
break; /* End of the directory stream. */
}
}
else
{
namep = dp->d_name;
/* Skip "", ".", and "..". "" is returned by at least one buggy
implementation: Solaris 2.4 readdir on NFS file systems. */
if (!namep[0] ||
(namep[0] == '.' && (namep[1] == 0 ||
(namep[1] == '.' && namep[2] == 0))))
continue;
}
/* rest of loop ... */
One of the key cases I recall is dp==NULL && errno == ERANGE, which
happened IIRC on a 32-bit Linux NFS client interoperating with an NFS
server running on an IRIX system with 64-bit inodes. Although even
NFSv2 allowed 32-byte file handles, I'd assume that the problem was in
the way that the server used readdir cookies.
Looking at the above the only case I can see that oldfind handles that
gnulib's fts does not is the case where the returned filename is
empty. That functionality is itself inherited from gnulib, due to
commit 49c86fdb3d58fc15ae14f804e0f69b681ff4fb70 (from June 2000).
According to Jim's accompanying comment the system of interest for
that workaround is Solaris 2.4, which IIRC gnulib dropped support for
some time ago.
James.
