[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 18:42:34 +0000 |
On 11/1/06, Daniel Richard G. <address@hidden> wrote:
On Wed, 2006 Nov 01 15:19:44 +0000, James Youngman wrote:
>
> Perhaps I was unclear. find needs to know how to handle the first
> DT_UNKNOWN entry when it sees it. (so does fts). IFF AFS guarantees
> that a DT_DIR entry will be seen before the first DT_UNKNOWN entry, we
> could automatically turn on the behaviour you are talking about, as
> long as we know the filesystem is AFS.
The "." and ".." entries are not a problem; they always scan as DT_DIR.
Any DT_UNKNOWNs will be non-directories, so they will appear
subsequently.
But my question is, does AFS guanrantee that readdir() will return
them in that order?
> >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?
>
> No, Find may need to call lstat() to determine the answer to other
> tests (-xtype, -type, -size for example). The find program needs to
> know if it should initially defer the lstat() on the grounds that it
> has eliminated the possibility that a directory is a directory.
It'll know from the get-go if an entry is a subdirectory or not, so no
problem there.
But I believe that only works if find has a way of knowing (without
stat()ing all the mount points) if a directory is in AFS or not.
But lstat() on the DT_UNKNOWN entries will always fail. The idea is
simply to make find(1) aware of this, so that it can save itself the
trouble.
What I also wanted to suggest was more graceful handling of the "we
really can't tell what this entry is" case, by adding a "-type u" test.
Yes, that's a good idea. Could you log this as a separate bug on
Savannah? (svannah.gnu.org). The same thing could also be useful
for entries in directories which allow r but not x.
> The priorities for find are security and correctness. Performance is
> a way lower priority. So I am interested in Doing The Right Thing,
> which is why I asked the questions I asked. I have no access to AFS
> so that's why I needed you to help me by answering the questions I
> asked.
Doing my best. (Doesn't gnu.org have an AFS cell?)
Not as far as I know. Anyway, I have no AFS client software.
James.
- 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., 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 <=
- 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