RE: Bug in find version 4.1.7

[Englisch, Volker (NIH/NCI)]

Hi James, 

thank you for your explanation of why find(1) produces the error message.
I've also studied the info file a bit more and realized that I could have
avoided the error message using your suggestion as well as using the 
"-depth" option, which causes find to first process the content of a 
directory before it processes the directory itself.

I do agree that you certainly don't want to make any changes to the code
if it makes it either unreliable or it degrades the performance.
However, from a user point of view I did found it odd for the program to 
return with an error message and then to find out that the directory in 
question had been removed as expected.

I'm wondering if it might be helpful to add a comment to the info file under

the section "Cleaning Up" in which the find command is listed in an example
with the 
  -exec rmdir {} \;
option.

Again, thanks for you response.

Volker Englisch
Contractor - MSD, Inc.
phone: (301) 496-0102  (CIPS)
mailto:address@hidden



-----Original Message-----
From: James Youngman [mailto:address@hidden 
Sent: Friday, April 09, 2004 9:28 AM
To: Englisch, Volker (NIH/NCI)
Cc: 'address@hidden'
Subject: Re: Bug in find version 4.1.7


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