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