Find / cd mount bug?

Garance A Drosihn drosih at rpi.edu
Sun Jun 6 23:32:04 GMT 2004


At 9:06 AM +0100 6/4/04, Richard Caley wrote:
>I thought this weird behaviour might be of interest to anyone
>working on the relevent bits of code. ...
>
>    $ find /cdrom -name \*.mp3 | wc
>         49      49    3387
>
>    $ find /cdrom -name \*.mp3 -type f | wc
>          77      77    5214
>
>Ie adding an extra restriction increases the number of results.
>The first one isn't giving an error at the point where it stops.

This is almost certainly an optimization in `find', where it
expects that the link-count for a directory is equal to the
number of sub-directories + 2.  The +2 is assumed to be '.'
and '..'.  But some file systems do not really have links for
'.' and '..'.

What happens is that something in `find' believes that once it
has found "link-count - 2" directories, than it must have found
all the real sub-directories in that directory.  By making this
assumption, it can avoid of doing a lot of unnecessary stat()
calls.  But on file systems which do *not* have links for '.'
and '..', this will result in `find' skipping the last two real
sub-directories -- without thinking that any error has occurred.

By adding the extra restriction, `find' *must* do the extra stat()
calls anyway, so it can not perform this optimization.  Note that
in some situations, this optimization can result in a pretty
significant performance boost, so it is worth doing (when it
works correctly... :-).

I know this problem shows up on some CD-ROM file systems, but I
don't know if it happens on all of them.  I also haven't looked
into `find' specifically, but I know I ran into this on some
other programs which perform this optimization.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu


More information about the freebsd-stable mailing list