Fwd: find -noleaf

[James Youngman]

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 <address@hidden>
Date: May 4, 2007 11:26 PM
Subject: Re: find -noleaf
To: Gregg Tracton <address@hidden>


On 5/4/07, Gregg Tracton <address@hidden> 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/address@hidden/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.


> address@hidden 177: mkdir theDir
> address@hidden 178: touch theDir/theFile
> address@hidden 179: find .
> .
> ./theDir
>
>
> --> OK, so that's the symptom: 'find' does not print a line for
> theDir/theFile
>
>
> address@hidden 183: find -noleaf
> .
> ./theDir
> ./theDir/theFile
>
> --> Good: -noleaf works as advertised
>
>
> address@hidden 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:
>
> address@hidden 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.
>
> address@hidden 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
>
> address@hidden 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.