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: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Eric BlakeOpen/Closed: Closed
Release: 4.3.8Fixed 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by ericb (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 02 Dec 2007 01:47:15 PM UTCjayOpen/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.3.11
    Sun 02 Dec 2007 11:43:50 AM UTCjayStatusIn Progress=>Fixed
    Fri 30 Nov 2007 10:58:28 AM UTCjayStatusConfirmed=>In Progress
      Assigned toNone=>jay

    Back to the top


    Powered by Savane 3.1-cleanup1