[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #23, bug #24140 (project findutils): Hmm. So looking at d_type by itself yields normal directories, but not mount points, or directory symlinks. Symlinks aren't such a big deal, but I notice that even though mount points read as DT_UNKNOWN, you can still stat() them. Not that it

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #21, bug #24140 (project findutils): Jeff, great to have your input here. One wrinkle in the nature of this bug is that it occurs only when the AFS client has (l)ist but not (r)ead access in a directory. A suitable AFS path for testing thus might not be available. Moreover, bec

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #19, bug #24140 (project findutils): Providing an actual system to work on is a bit tricky, since AFS tends to be an institutional thing, and bureaucracy gets in the way. For my part, the installation I use is part of a corporate network---not only do I doubt you'd want to sign

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #17, bug #24140 (project findutils): Hi James, good to hear from you again. I'd still like to find a fix for this, because the epic slowness continues to be an issue in AFS. Would it be helpful if you had access to an AFS system on which to test? While I can't provide a system

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #13, bug #24140 (project findutils): Okay, I've done some investigation on this. First off, as you suspected, there's not much than can be done for ftsfind. I think the fts backend could be modified to handle AFS gracefully, but that goes beyond the scope of this project. For

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #11, bug #24140 (project findutils): Interesting. I'll have a look at that. But to answer one question... /tmp/foo.iso on /afs/example.com/user/skunk/blah type iso9660 (rw,loop=/dev/loop0) Yes. And the same likely goes for bind mounts. I seem to recall there was an --enable-a

Re: [bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Hi Jeffrey, On Mon, 2008 Sep 01 20:25:11 -0400, Jeffrey Hutzelman wrote: > --On Monday, September 01, 2008 11:12:31 PM +0000 "Daniel Richard G." > <[EMAIL PROTECTED]> wrote: > > >If we use libafs, we may as well go all the way and have find(1) check > >the

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #9, bug #24140 (project findutils): You would be open to a compile-time option to link against the AFS libraries? (I was under the impression that this existed in past versions, and was removed at some point.) If we use libafs, we may as well go all the way and have find(1) che

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #6, bug #24140 (project findutils): I get your first paragraph, but I don't understand what you're responding to in the second and third. Let me try this again: We know what the behavior needs to be in order to avoid the 3-second-stat()s-on-AFS problem: if opendir() returns a d

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #4, bug #24140 (project findutils): Please see comment #2. The question is, "Should find(1) have an option that causes it to trust d_type=DT_UNKNOWN, or should it specifically check for AFS and do the same without user intervention when working inside that filesystem?" I recogn

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

Follow-up Comment #2, bug #24140 (project findutils): Should there be an option, along the lines of -noleaf, that causes find(1) to believe what d_type says for unknown entries? Would you rather have find(1) autodetect AFS in some way to adapt its behavior on-the-fly? (IIRC, this would basically

[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

URL: Summary: Painfully slow find(1) in list-permission-only AFS paths Project: findutils Submitted by: iskunk Submitted on: Tue 26 Aug 2008 07:03:01 AM GMT Category: find

Re: Problem with find + AFS + acl="l"

oot directory is on NFS---in which case the system has bigger problems anyway :-) Is there any more information I can provide about AFS behavior? --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = [EMAIL PROTECTED]## don't smell bad---(

Re: Problem with find + AFS + acl="l"

If you could enumerate the ways in which a canonical path might not be obtainable, I can test to see if any of them apply to AFS. --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = [EMAIL PROTECTED]## don't smell bad---(/o|o\) / EMAI

[bug #18174] [wishlist] Add "-type u" test for paths with unknown type

URL: Summary: [wishlist] Add "-type u" test for paths with unknown type Project: findutils Submitted by: iskunk Submitted on: Thursday 11/02/2006 at 04:55 Category: find

Re: Problem with find + AFS + acl="l"

at 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 th

Re: Problem with find + AFS + acl="l"

sked. 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 = [EMAIL PROTECTED]

Re: Problem with find + AFS + acl="l"

On Wed, 2006 Nov 01 13:15:52 +, 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 >

Problem with find + AFS + acl="l"

e find /afs/example.com/volume -nostat_unknown -type f -o -type u or, perhaps, find /afs/example.com/volume -nostat_unknown ! -type d to obtain my desired result. Thoughts and comments will be greatly appreciated. --Daniel -- NAME = Daniel Richard G.