bugfindutils - Bugs: bug #50058, [wishlist] -prune a subdir(tree)...


bug #50058: [wishlist] -prune a subdir(tree) when a file therein matches criteria

Submitter:  Jochen Bern <bern>
Submitted:  Mon 16 Jan 2017 02:18:40 PM UTC
Category:  find Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.4.2 Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Tue 17 Jan 2017 08:46:50 PM UTC, comment #3: 

True, -depth causes the elements of a directory to be processed before the directory itself.  But there's no specified way to affect the order in which the items in a directory are processed.  I suspect this comes from the semantics of opendir/readdir/closedir in the earliest versions of Unix.  The only way find could get around this is to read directories completely when it first enters them and sort the entries itself.  Unfortunately, this would make find vulnerable to bad behavior on very large directories.

OTOH, one could use nested invocations of find, as in this gruesome command line:

find /dir -type d -exec find . -maxdepth 1 -type f -newer XXX \; -prune -print -false

Dale Worley <worley>
Mon 16 Jan 2017 04:51:37 PM UTC, comment #2: 

Hmmm, point taken. (The application I'm debugging has a couple base dirs and puts the actual files a fixed number of directories, named per hash values, underneath them, so the question didn't come up for me.)

However, the problem isn't entirely new. For cases where the processing order of directories may influence the result, find already provides the -depth option. Also, the order of files within a single directory remains officially undefined, though it may show in the output.

Unless I'm missing something, the case you present would yield an unambiguous result as soon as it were pinpointed whether, within a single directory, find shall process "files before subdirs" (-> result: A2) or "subdirs before files" (-> result: A1a and A2).

... that raises the question, however, whether find's code does or could obey such a search order, as of now?

Jochen Bern <bern>
Mon 16 Jan 2017 03:35:53 PM UTC, comment #1: 

First, I think you need to define carefully the semantics of your proposal and consider its implications.

As I read what you wrote, which files/directories are examined by find would depend on the order in which directories were examined.  There is no way to control that order, and no existing find predicate is affected in that way.

And as you've written the example, it would not behave as desired.  Consider this structure:


Suppose files A1a and A2 are "recently updated 'certain' files".  If find walks the tree in the order shown, find will not see A2 (and thus attempt to prune all of A) until after A1a has been examined.

To truly meet the stated requirements, you'll have to scan the entire tree for updated files and then post-process that list to find the required directories.

Dale Worley <worley>
Mon 16 Jan 2017 02:18:40 PM UTC, original submission:  

Today, I needed to find the subdirs in a large-ish tree where the application had recently created/updated certain files. So, upon finding such a file, I would have liked to -prune the directory (and its subdirectories) its entry is in.

Unfortunately, -prune works only if find is actually looking at the directory itself; it does not have any defined effect if the "file currently examinated" is in fact a file.

Would it be possible to implement "-prune $THIS" to, in pseudocode, have the effect of "-type d -prune $THIS -o -prune `dirname $THIS`"?

Jochen Bern <bern>


(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 worley (Posted a comment)
  • -email is unavailable- added by bern (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.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code