On 10/28/06, Daniel Richard G. <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
