[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in find version 4.1.7

From: James Youngman
Subject: Re: Bug in find version 4.1.7
Date: Fri, 9 Apr 2004 14:28:07 +0100
User-agent: Mutt/1.3.28i

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]