You are right, directories are odd, files are even.
The original Andrew folk wrote a tool called "ws" which is an
AFS-aware find that takes advantage of the inode numbering. You can
find sources and "help pages" in /afs/psc.edu/usr/ecf/src/ws.
On Apr 7, 2005 9:48 AM, Jim Rees <[EMAIL PROTECTED]>
On Thursday, April 07, 2005 09:48:20 AM -0400 Jim Rees <[EMAIL PROTECTED]>
wrote:
A bit off the subject, but the way to really speed up "find" is to store a
flag in the directory that says whether each leaf is a file or directory.
That way you avoid stat on regular files if there are no other pr
A bit off the subject, but the way to really speed up "find" is to store a
flag in the directory that says whether each leaf is a file or directory.
That way you avoid stat on regular files if there are no other predicates
that require it.
This can be done in afs by cheating, because the viceid is
At 3:25 PM -0400 4/5/05, Rodney M Dyer wrote:
At 03:09 PM 4/5/2005, you wrote:
gnu find is not the same as solaris find. the -noleaf option is
the equivalent of the default options with solaris (well, unix)
find. so since gnu find goes out of its way to work this way,
when other finds do not, i see
Rodney M Dyer <[EMAIL PROTECTED]> writes:
> That sort-of makes sense. Sorry, I wasn't suggesting that the bug was
> in AFS, or find. I just think it is kind of silly that it works that
> way. Why not "fix" the gnu find so that it requires the "-noleaf"
> option in all circumstances, or a stupid
At 03:09 PM 4/5/2005, you wrote:
gnu find is not the same as solaris find. the -noleaf option is the
equivalent of the default options with solaris (well, unix) find. so since
gnu find goes out of its way to work this way, when other finds do not, i
see no reason why the filesystem should go out
On Tuesday, April 05, 2005 15:03:30 -0400 Rodney M Dyer <[EMAIL PROTECTED]>
wrote:
At 01:49 PM 4/5/2005, Derrick J Brashear wrote:
use the -noleaf option to find. it's not an afs bug, so you found no bug.
Actually, why isn't this a bug? He doesn't need the -noleaf option if
there is at least on
Rodney M Dyer wrote:
At 01:49 PM 4/5/2005, Derrick J Brashear wrote:
use the -noleaf option to find. it's not an afs bug, so you found no bug.
Actually, why isn't this a bug? He doesn't need the -noleaf option if
there is at least one other "real" directory in the root of the
directory he is t
On Tue, 5 Apr 2005, Rodney M Dyer wrote:
At 01:49 PM 4/5/2005, Derrick J Brashear wrote:
use the -noleaf option to find. it's not an afs bug, so you found no bug.
Actually, why isn't this a bug? He doesn't need the -noleaf option if there
is at least one other "real" directory in the root of the
At 01:49 PM 4/5/2005, Derrick J Brashear wrote:
use the -noleaf option to find. it's not an afs bug, so you found no bug.
Actually, why isn't this a bug? He doesn't need the -noleaf option if
there is at least one other "real" directory in the root of the directory
he is testing.
Rodney
___
On Tue, 5 Apr 2005, Jonathan E Halter wrote:
This is on: RHEL WS3, kernel 2.4.21-27.EL, openafs 1.2.13
I'm wondering if anyone else can recreate this problem I've come across
with using the find command in AFS. I don't know if its a problem with
the RHEL's find command, the OpenAFS client, or a com
This is on: RHEL WS3, kernel 2.4.21-27.EL, openafs 1.2.13
I'm wondering if anyone else can recreate this problem I've come across
with using the find command in AFS. I don't know if its a problem with
the RHEL's find command, the OpenAFS client, or a combination of the 2.
I do NOT have this probl
12 matches
Mail list logo
