bugfindutils - Bugs: bug #42985, find reports "No such file or...


bug #42985: find reports "No such file or directory" when executing rm

Submitter:  None
Submitted:  Thu 14 Aug 2014 10:49:54 AM UTC
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Works For Me
Privacy:  Public Assigned to:  jay
Originator Name:  Alexander Ewering Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.2
Fixed Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 14 Nov 2017 10:53:45 PM UTC, comment #9: 

> find $(pwd) . -mindepth 1 -maxdepth 1 -regex $cpat -prune -o -exec rm -rfv {} \+ >/dev/null 2>../error.log

The documentation explains why you should not do that.

9.3 Cleaning Up

This section gives examples of removing unwanted files in various
situations.  Here is a command to remove the CVS backup files created when an update requires a merge:

     find . -name '.#*' -print0 | xargs -0r rm -f

   If your 'find' command removes directories, you may find that you get a spurious error message when 'find' tries to recurse into a directory that has now been removed.  Using the '-depth' option will normally resolve this problem.

James Youngman <jay>
Project Administrator
Fri 22 Sep 2017 10:01:58 AM UTC, comment #8: 

Btw I think that errors come when `find` has to utilize several `rm` calls basing on command line length limitations.

Andrii <andrii>
Fri 22 Sep 2017 09:56:06 AM UTC, comment #7: 

The case comes from complex environment where `find` accepts list of folders. In some cases that list may have duplicate entries, just represented by different paths.
It looks the safest way for such setup is to handle each folder separately.

Andrii <andrii>
Fri 22 Sep 2017 09:31:54 AM UTC, comment #6: 

It produces much more output in my environment (I did it on /dev/shm), but - without having a closer look - my guess is
that find does not wait for rm to finish and continues reading
with the next argument ... that's something I don't understand
anyway: why do you run find with /those/ 2 arguments?
  find $(pwd) .
This looks redundant, and when I only pass one of them, then
the test on my /dev/shm doesn't output any errors anymore.

Bernhard Voelker <berny>
Project Administrator
Fri 22 Sep 2017 08:48:12 AM UTC, comment #5: 

Thank you a lot for explanations - I am sure they will be valuable for everyone who encounters similar error from `find rm`.

It also helped me to create following test case for huge amount of input data, in which the suggestions don't seem to help.

Warning: the script puts high load on filesystem, so use it only in good test environment.

mkdir -p 42985
set -e
cd 42985
echo creating many folders
for i in {1..10000}; do n=$(echo $i | md5sum); n=${n%% *}; mkdir $n; touch $n/$n $n/${n}1 $n/${n}2 ; done &gt; /dev/null
if ! find $(pwd) . -mindepth 1 -maxdepth 1 -regex $cpat -prune -o -exec rm -rfv {} \+ &gt;/dev/null 2&gt;../error.log ; then
        echo &quot;there were errors:&quot;
        head ../error.log
        echo success

The produced output in my environment:

creating many folders
there were errors:
find: ‘./041f49053a1b6be294e4149b75b997b4’: No such file or directory
find: ‘./1b6bbdb9e57e72c47bca951947563fc9’: No such file or

Please let me know if this looks like valid bug and whether I should create dedicated report for it.

(I know the workaround will be using unique entries in input folder list or handing one folder per call, just hopefully find can manage this job anyway).

Andrii <andrii>
Thu 21 Sep 2017 06:47:32 AM UTC, comment #4: 

Well, this is the result of the order of processing in 'find'
disturbed by the deletion action of 'rm'.

First, let's see what find would call in which order if 'rm'
would not get in its way by putting 'echo' in front of 'rm':

  1. $ find $(pwd) . -mindepth 1 -exec echo rm -rf '{}' \;

1  rm -rf /home/a/findtest/1
 2  rm -rf /home/a/findtest/1/b
 3  rm -rf /home/a/findtest/1/a
 4  rm -rf /home/a/findtest/2
 5  rm -rf /home/a/findtest/2/b
 6  rm -rf /home/a/findtest/2/a
 7  rm -rf ./1
 8  rm -rf ./1/b
 9  rm -rf ./1/a
10  rm -rf ./2
11  rm -rf ./2/b
12  rm -rf ./2/a

Already with command on line 1 'rm' would remove the directory '1'.
Then, 'find' would continues to search for the content of '1' (from
which it knows that it is a directory from before), but that does
not exist anymore. That's why find complains about that in your example.
The same applies to the directory '2'.

For what it's worth, find does not complain about anything below the
2nd command line argument "." because at the time find starts processing
that argument, there is no content which would match '-mindepth 1'.

The following is similar to your command but uses

  • a -printf action before the -exec option to see what command it would call,
  • and with 'rm -v' to see what file is actually deleted at which time,

thus proving the above explanation:

  0  $ find $(pwd) . -mindepth 1 -printf "debug: call rm for '%p'\n" -exec rm -rv '{}' \;
  1  debug: call rm for '/home/a/findtest/1'
  2  removed ‘/home/a/findtest/1/b’
  3  removed ‘/home/a/findtest/1/a’
  4  removed directory: ‘/home/a/findtest/1’
  5  find: ‘/home/a/findtest/1’: No such file or directory
  6  debug: call rm for '/home/a/findtest/2'
  7  removed ‘/home/a/findtest/2/b’
  8  removed ‘/home/a/findtest/2/a’
  9  removed directory: ‘/home/a/findtest/2’
 10  find: ‘/home/a/findtest/2’: No such file or directory

The lines 2-4 are the output of the first rm command incovation
for the directory '/home/a/findtest/1' as stated in line 1.
In line 5, find complains about the same directory not there
any more.

What you probably want is using a depth-first processing,
i.e., the '-depth' option:

  $ find $(pwd) . -mindepth 1 -depth -printf "debug: call rm for '%p'\n" -exec rm -rv '{}' \;
  debug: call rm for '/home/a/findtest/1/b'
  removed ‘/home/a/findtest/1/b’
  debug: call rm for '/home/a/findtest/1/a'
  removed ‘/home/a/findtest/1/a’
  debug: call rm for '/home/a/findtest/1'
  removed directory: ‘/home/a/findtest/1’
  debug: call rm for '/home/a/findtest/2/b'
  removed ‘/home/a/findtest/2/b’
  debug: call rm for '/home/a/findtest/2/a'
  removed ‘/home/a/findtest/2/a’
  debug: call rm for '/home/a/findtest/2'
  removed directory: ‘/home/a/findtest/2’

Thus said, I think this is all expected behaviour.

BTW: creating one 'rm' process per file is not very elegant, and
even unnecessary with 'rm -r' as that operates recursively.
This would create only one process per file found in the current
directory, and leave the recursive processing up to 'rm':

  $ find $(pwd) -mindepth 1 -maxdepth 1 -exec rm -rv '{}' \;

... or even use "find ... -exec ... +" to have as many 'rm' processes
as necessary, maybe only one.

Have a nice day,

Bernhard Voelker <berny>
Project Administrator
Thu 21 Sep 2017 02:49:46 AM UTC, comment #3: 

I can observe the problem with case below (not sure if it is really a bug though)

$ cd ~/findtest
$ mkdir 1
$ mkdir 2
$ touch 1/a 1/b 2/a 2/b
$ find $(pwd) . -mindepth 1 -exec rm -rf {} \;
find: ‘/home/a/findtest/1’: No such file or directory
find: ‘/home/a/findtest/2’: No such file or directory

Andrii <andrii>
Sun 01 Nov 2015 10:17:33 PM UTC, comment #2: 

Closing due to lack of response.

James Youngman <jay>
Project Administrator
Tue 26 Aug 2014 10:24:46 PM UTC, comment #1: 

This is a very very vague bug report.

When reporting a bug in any software, please state
1. What specifically you did
2. What you expected to happen
3. What, specifically and in detail, did happen.

I'm not able to reproduce the symptom you are describing, either:

~/tmp$ mkdir t
~/tmp$ cd t
~/tmp/t$ touch x
~/tmp/t$ mkdir d
~/tmp/t$ touch d/yy
~/tmp/t$ find . -exec rm {} \;
rm: cannot remove `.': Is a directory
rm: cannot remove `./d': Is a directory
~/tmp/t$ find .

If you can reproduce this problem please post a more detailed bug report.

James Youngman <jay>
Project Administrator
Thu 14 Aug 2014 10:49:54 AM UTC, original submission:  

When executing something that deletes files (-exec rm "{}", for example), find will report "No such file or directory" for each file that it processes... very confusing... seems like it tries to access the file again after executing the command...?



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by andrii (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-01 jay StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2014-08-26 jay StatusNone Need Info
    2014-08-26 jay Assigned toNone jay

    Back to the top

    Powered by Savane 3.9