GNU bug report logs - #29568
Bug in find, or my mistake ?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29568 in the body.
You can then email your comments to 29568 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <f0rhum <at> free.fr>
To: bug-coreutils <at> gnu.org
Subject: Bug in find, or my mistake ?
Date: Mon, 4 Dec 2017 22:34:39 +0100

[Message part 1 (text/plain, inline)]

Hi
find -version
find (GNU findutils) 4.4.2

I issued this command to remove all files "*_original" from parent tree :
/find .. iname "*_original" -delete/
as you see I forgot the minus sign before /iname/.
The result was all regular files were deleted, just leaving behind empty
directories (I don't really know why dirs remained, maybe because it is
a synchronised folder with some exclusions that prevented remote
deletion and the local were created back).
Is it because /iname/ and /"*_original"/ are both seen as EXPRESSIONS
that always return true so that -delete applies to .. and content as a
whole ?

Thanks
//

[Message part 2 (text/html, inline)]

Message #8 received at 29568 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: f0rhum <f0rhum <at> free.fr>, 29568 <at> debbugs.gnu.org,
 "bug-findutils <at> gnu.org" <bug-findutils <at> gnu.org>
Subject: Re: bug#29568: Bug in find, or my mistake ?
Date: Tue, 5 Dec 2017 10:30:27 +0100

tag 29568 notabug
close 29568
thanks

On 12/04/2017 10:34 PM, f0rhum wrote:
> Hi
> find -version
> find (GNU findutils) 4.4.2

First of all, find(1) belongs to the "GNU findutils" rather than "GNU coreutils".
==> CCing bug-findutils <at> gnu.org

> I issued this command to remove all files "*_original" from parent tree :
> /find .. iname "*_original" -delete/
> as you see I forgot the minus sign before /iname/.

outch.

> The result was all regular files were deleted, just leaving behind empty
> directories (I don't really know why dirs remained, maybe because it is
> a synchronised folder with some exclusions that prevented remote
> deletion and the local were created back).
> Is it because /iname/ and /"*_original"/ are both seen as EXPRESSIONS
> that always return true so that -delete applies to .. and content as a
> whole ?

I'm sorry for you, but actually find exactly did what you told it to do.
The tool takes all command line arguments until the first expression
as file argument:

  $ find --help | sed 4q
  Usage: find [-H] [-L] [-P] [-Olevel] [-D debugopts] [path...] [expression]

  default path is the current directory; default expression is -print
  expression may consist of: operators, options, tests, and actions:
  ...

Therefore, you passed "..", "iname", and "*_original" as path arguments.
As the two latter probably do not exist literally, you probably got these
error messages:

  find: cannot delete ‘..’: Directory not empty
  find: ‘iname’: No such file or directory
  find: ‘*_original’: No such file or directory

The -delete action is a delicate one, so I usually run find without that
action first to see what files would get deleted.

There's nothing we can do here at GNU coreutils, and I'm quite sure
the findutils folks (which I am part of, too) can't do either.

Anyway, I'm closing this as not-a-bug in the coreutils bugtracker.

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.