[bug #20802] find -delete anomalies

[Eric Blake]

URL:
  <http://savannah.gnu.org/bugs/?20802>

                 Summary: find -delete anomalies
                 Project: findutils
            Submitted by: ericb
            Submitted on: Friday 08/17/2007 at 11:42
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: Confirmed
                 Privacy: Public
             Assigned to: None
         Originator Name: Eric Blake
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.3.8
           Fixed Release: None

    _______________________________________________________

Details:

Shouldn't a failed -delete cause a non-zero exit status, because an error
message was printed to stderr?

$ mkdir a
$ cd a
$ mkdir b
$ touch b/c
$ find -type d -empty -delete
find: cannot delete `./b': Directory not empty
$ echo $?
0

Or since the -delete action results in false on failure, is it still
necessary to also print to stderr?

Likewise, shouldn't -delete attempt (and fail) to delete ., if it has not
been filtered out by a prior expression (such as via -empty, -type f,
-mindepth, etc.)?  Here, the fact that . is printed without an error means
that find claims to have deleted ., which is inconsistent (note that even on
platforms where you are permitted to remove the current working directory, you
have to do so via the named directory entry in .., rather than via `.').

$ rm b/c
$ rmdir .
rmdir: .: Invalid argument
$ find -type d -delete -print
./b
.
$ echo $?
0
$ 

It may be worth comparing this bug report to the results of a recent
coreutils thread, asking for a way come up with a list of successfully deleted
leaf directories (including parents that become leaves during the recursion),
while being silent with regards to non-empty directories:
http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00069.html





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?20802>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/