bugfindutils - Bugs: bug #20802, find -delete anomalies

 
 

bug #20802: find -delete anomalies

Submitted by:  Eric Blake <ericb>
Submitted on:  Fri 17 Aug 2007 05:42:30 PM UTC  
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Eric Blake Open/Closed:  Closed
Release:  4.3.8 Fixed Release:  4.3.11

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 30 Nov 2007 10:58:28 AM UTC, comment #1: 

I've changed the code such that if -delete fails, find's exit status will be nonzero. 

One of the reasons that we skip deletion of "." is for compatibility with *BSD, where this action originated.   I'm certainly willing to further discuss the removal of this special case, but I would prefer to mark this particular bug as fixed.  So, if you'd like to press for removal of the special case, please go ahead and open a fresh bug for that.   Thanks.

James Youngman <jay>
Project AdministratorIn charge of this item.
Fri 17 Aug 2007 05:42:30 PM UTC, original submission:  

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

Eric Blake <ericb>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

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 jay (Posted a comment)
  • -email is unavailable- added by ericb (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-12-02 jay Open/ClosedOpen => Closed
        Fixed ReleaseNone => 4.3.11
    2007-12-02 jay StatusIn Progress => Fixed
    2007-11-30 jay StatusConfirmed => In Progress
        Assigned toNone => jay

    Back to the top


    Powered by Savane 3.5