[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with find + AFS + acl="l"
From: |
Daniel Richard G. |
Subject: |
Re: Problem with find + AFS + acl="l" |
Date: |
Wed, 1 Nov 2006 10:00:42 -0500 |
On Wed, 2006 Nov 01 13:15:52 +0000, James Youngman wrote:
> 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.
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 = address@hidden ## don't smell bad--- (/o|o\) /
EMAIL2 = address@hidden ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l",
Daniel Richard G. <=
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/02
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/03
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/03