[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

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

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.


reply via email to

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