Excerpts from dl.info-afs: 20-Jun-96 Re: using find in AFS file .. Fred
[EMAIL PROTECTED] (2417*)
> the GNU version of find by default does not enter directories that are
> mount-points because it does a 'smart' check in every directory. It
> checks whether the number of links on the current directory is not
> larger than 2 ('.' and '..').
Actually, that's not quite correct. When entering a directory, GNU find
checks and remembers the link count. Every time it encounters a
directory, it subtracts one from this count. When the count reaches 2,
then GNU find assumes no more subdirectories exist in the current
directory, and therefore won't stat() any of the remaining files in the
directory unless an action which requires calling stat(), such as "-ls",
was given. This optimization works in any UFS based on the Berkeley
Fast File System, because the BFFS guarantees that the link count for a
directory is always the sum of the subdirectories (including "." and
"..") it contains.
But since AFS implements mountpoints as symbolic links, and symbolic
links do not increment the stat count, this optimization is not valid in
an AFS filesystem. Unless you use the "-noleaf" option to GNU find,
every mountpoint you create in a directory translates into a
directory/mountpoint which GNU find will "miss" when traversing the
directory. It won't necessarily miss the mountpoint you created,
either. For example, if you create a new directory, and then create
first a subdirectory and then a mountpoint in that directory, GNU find
won't descend into the mountpoint, because the subdirectory appears
first in the directory entry, and GNU find's stat count will be 2 after
traversing the subdirectory. If, however, you created the mountpoint
first, and *then* create the subdirectory, it's the *subdirectory* which
GNU find will not descend, because it will encounter the mountpoint (and
traverse it, and decrement the stat count) first.
So, it is *not* the case that a non-AFS-aware GNU find (without the
"-noleaf" option) will not cross AFS mountpoints. Rather, it will
"randomly" not descend into mountpoints and/or subdirectories, where
"randomly" is actually determined by the number of mountpoints which
appear in the directory entries, and the order in which they appear.
Since this behavior is rarely desirable, it's almost a necessity to
always use "-noleaf" when using a non-AFS-aware GNU find in AFS space.
I haven't had a chance to evaluate GNU findutils4.1. Hopefully, besides
turning off the link count optimization in AFS space, the AFS-aware GNU
find will additionally allow some sort of a "-type m" test for AFS
mountpoints.
--
James Crawford Ralston \ [EMAIL PROTECTED] \ Systems and Networks [CIS]
University of Pittsburgh \ 600 Epsilon Drive \ Pittsburgh PA 15238-2887
"Computer, you and I need to have a little talk." - O'Brien, ST:DS9
