[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 12:23:04 -0500 |
User-agent: |
Mutt/1.5.9i |
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.
> >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 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.
> Doing this with a switch
>
[...]
I'd be fine with automagic activation of the modified behavior, as long
as a compile-time option isn't needed. I'd like standard distribution
packages to work.
One advantage of having a switch, however, is that it may be useful in
contexts outside of AFS. This same situation might crop up on, say,
Coda, or some lesser-known fs....
> 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?)
--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., 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/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