Re: Problem with find + AFS + acl="l"

[James Youngman]

On 10/28/06, Daniel Richard G. <address@hidden> wrote:
> I am using find(1) at an AFS site to produce file lists for indexing.

Unfortunately you don't indicate which version.  It would be very
useful if you did.


[...]
> The current behavior of find(1) is problematic because in these restricted
> directories, readdir() returns a dirent->d_type of either 4 (DT_DIR, if the
> entry is a directory) or 0 (DT_UNKNOWN, if it is anything else). Though I
> am not using a -type test, find(1) calls lstat() on the DT_UNKNOWN entries,
> which invariably returns -1/EACCES. I've observed cases where each failed
> stat takes *two or three* seconds to return, due to AFS weirdness, and even
> when it returns immediately the sheer number of stats performed needlessly
> spikes network traffic and latency.

find uses lstat to determine if it shoud recurse into that entry.   It
assumes that entries for which DT_UNKNOWN was returned much be
directories (since readdir didn't seem to know).

IFF AFS has these properties:
1. "." and ".." are returned first
2. DT_DIR is returned for them

... then we could defer the lstat call until the point where we need
information about the file.     I think that would meet your
requirements.  But we should only do that if CONFIG_AFS was supplied
AND we're sure the directory is an AFS directory (that is, we are sure
that no entry for which DT_UNKNOWN is returned could ever be a
directory).

How can we determine this?  Does AFS guarantee the properties I describe?

How do the results differ if you use the ftsfind in findutils 4.3.x?

James.