[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Youngman
Subject: Re: Problem with find + AFS + acl="l"
Date: Wed, 1 Nov 2006 13:15:52 +0000

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]