Contrary to what I wrote below, I had not copied this to the list.
I'm now doing so. Did you get a chance to retest your problem with
a modern version of findutils?
---------- Forwarded message ----------
From: James Youngman <[EMAIL PROTECTED]>
Date: May 4, 2007 11:26 PM
Subject: Re: find -noleaf
To: Gregg Tracton <[EMAIL PROTECTED]>
On 5/4/07, Gregg Tracton <[EMAIL PROTECTED]> wrote:
Hi!
Hi, I am copying this email to the mailing list. I hope you don't mind.
We have multiple deadlines for paper so I've been delaying answering
your questions.
Thanks for getting back to me and being so patient.
Here's a little experiment that may suggest that when the filesystem is
"UNKNOWN" then 'find' should disable leaf optimization,
I underatand your point. Unfortunately, find tries to defer figuring
out filesystem types. On many platforms it needs to stat all the
entries in /etc/fstab to do this, and if the system is a client of any
unresponsive NFS server, this can cause find to hang (specifically,
get stuck in the 'D' state).
in addition to testing st_nlinks < 2. On an AFS disk:
Aha, AFS! Did you compile using the --with-afs option to configure?
Did it work? You might also want to read an earlier thread on this:
http://www.mail-archive.com/[email protected]/msg01242.html
My ability to test things with AFS is pretty much nonexistent. Even
if I could build a system with AFS support, there are few AFS cells
offering write access to unidentified users, I'd guess.
[EMAIL PROTECTED] 177: mkdir theDir
[EMAIL PROTECTED] 178: touch theDir/theFile
[EMAIL PROTECTED] 179: find .
.
./theDir
--> OK, so that's the symptom: 'find' does not print a line for
theDir/theFile
[EMAIL PROTECTED] 183: find -noleaf
.
./theDir
./theDir/theFile
--> Good: -noleaf works as advertised
[EMAIL PROTECTED] 186: stat -f theDir
File: "theDir"
ID: 6300001234 Namelen: 256 Type: UNKNOWN (0x0)
Blocks: Total: 9000000 Free: 9000000 Available: 9000000 Size: 1024
Inodes: Total: 9000000 Free: 9000000
Oops, UNKNOWN should prob'ly be AFS.
What's going on there?
See my remarks above. But by using -f you have suppressed the very
information I need; link counts. What is the full stat information
for "theDir/.." ?
> For a while now findutils has been automatically turning off the leaf
> optimisation for directories where the link count is less than 2. I
> would expect filesystems not honouring the traditional (but not
> standards-enforced) semantics of directory hard link counts should
> simply offer st_nlink=1 for directories.
>
> Are you seeing behaviour which isn't consistent with these
> assumptions? If so, precisely what are you seeing?
I think this may be inconsistant, if I'm understanding this right:
[EMAIL PROTECTED] 246: stat -c %h theDir
2
The relevant thing is the link count on the directory containing
theDir, not the link count on theDir itself.
And just to make sure you know my RHEL4 system & versions.
[EMAIL PROTECTED] 180: uname -a
Linux prome.radonc.unc.edu 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT
2005 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] 181: find --version
GNU find version 4.1.20
Findutils 4.1.20 was released in 2004. People born since its release
can talk now. Please upgrade, because otherwise I will not be able to
distinguish problems you are having now which are fixed from those
that are not. In particular where I wrote "for a while now..."
above, I mean _since_ 4.2.24 (released in 2005). In fact there is
quite a detailed explanation in the NEWS file in the entry for release
4.2.24.
I can provide openafs client and server version numbers if you're
interested.
They would mean nothing to me.
Tell me if I can provide any more info.
Could you let me know if the bug is still present in any version of
findutils released _after_ I started growing hairs out of my ears?
4.1.20 is quite old now. A suitably recent version would be 4.2.30,
though testing with 4.3.4 would also be useful. Anything after
4.2.24 would be acceptable, though still potentially confusing, so
please shoot for 4.2.30.
James.
_______________________________________________
Bug-findutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-findutils
