Re: Bug in find version 4.1.7

[James Youngman]

On Thu, Apr 08, 2004 at 07:46:51PM -0400, Englisch, Volker (NIH/NCI) wrote:
> Hi, 
> 
> I believe I just ran into a (minor) bug that I haven't seen reported in the
> archives.

[...]
$ find . -name dada -exec rmdir {} \;
find: ./dada: No such file or directory
[...]

This is caused by the fact that find(1) reads the contents of a
directory first and then acts on it.  Here, the entries within the
current directory are read, and then the -exec is performed.  The
find(1) command then conntinues to search recursively into
subdirectories, and finds that it can't recurse into 'dada' because
that directory has been removed.

There are only two ways I can see to properly solve this problem :-

1. Make "find" understand the effect of the command it's executing
   with -exec.  That's messy, unreliable and doesn't seem like a good
   design.

2. Make find reread the contents of a directory after each -exec.
   That would certainly impact its performance.  Therefore I'm not
   keen on this option either.

At each stage find(1) is acting in accordance with what it sees in the
filesystem, and it is doing what you told it to do.  I am not certain
then that this problem should really be called a "bug".

You can work around this specific manifestation of the problem by
using a pipe.  That way, find(1) finishes searching before the rmdir
takes place (this would not in general be the case if you were trying
to remove directories whose names together make up more than PIPE_BUF
bytes) :-

find . -type d -name dada -print0 | xargs -0 rmdir