On Wed, 2006 Nov 01 13:15:52 +0000, James Youngman wrote: > 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.
This was 4.2.27, sorry. I didn't see any discussion of this issue on the list, so assumed that CVS would be no different. > find uses lstat to determine if it shoud recurse into that entry. It > assumes that entries for which DT_UNKNOWN was returned might be > directories (since readdir didn't seem to know). I noticed that. With AFS, the assumption doesn't appear to hold. > 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). Provided that the opendir() call is permitted, AFS always returns DT_DIR for subdirectories, never DT_UNKNOWN---so recursion is not a problem. (IIRC, AFS does have some potential for weirdness with "." and "..", but I believe this was addressed by the -noleaf option.) That aside, I don't think that the remaining DT_UNKNOWNs have to be handled in an AFS-specific way. Wouldn't it be enough to have a switch that tells find(1) not to examine these entries further? The DT_UNKNOWN behavior will be consistent for any AFS path, and it is highly unlikely that you'll have find(1) scanning /afs and some other filesystem (with potentially different behavior) in the same invocation. > How can we determine this? Does AFS guarantee the properties I describe? I don't think I could use as strong a word as "guarantee," but the aforementioned is the standard behavior for directories with "l" access. AFS isn't returning DT_UNKNOWN willy-nilly; its design is deliberately such that if you have list permission on a directory, listing is _all_ you can do. You can see an entry, and see whether or not it is a subdirectory (in which you may or may not have access under a different ACL), but all other information is denied---even the specific non-directory file type. > How do the results differ if you use the ftsfind in findutils 4.3.x? I'll give it a try, but am presuming that fts_read() et al. won't fare any better than readdir(). --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = [EMAIL PROTECTED] ## don't smell bad--- (/o|o\) / EMAIL2 = [EMAIL PROTECTED] ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
