Update of bug #47261 (project findutils): Severity: 3 - Normal => 4 - Important Status: None => Need Info Assigned to: None => jay
_______________________________________________________ Follow-up Comment #1: This is very interesting, and of course surprising. Thanks for the comprehensive diagnositics. First of all, please try to reproduce the problem with the current stable release of find. You should be able to download version 4.6.0 from ftp.gnu.org/pub/gnu/findutils (you would need to build it yourself, I trust that this would not be a problem). Given the nature of the problem, I'm still interested in tracking down the problem with version 4.4.2 even if it's not reproducible in 4.6.0. Also, building 4.4.2 from source should generate two binaries. One is called find and is the one you will have used for your video etc. The other is called "oldfind". With version 4.4.2 some distributions include oldfind and some do not. I'd be interested in whether the problem is reproducible with oldfind (the two should be compatible and produce the same results but the internals are very different). You can also get additional information about what find is doing with the -D option. Try for example: oldfind -D search,stat,tree,opt / -iname 'firefox_binary.py' find -D search,stat,tree,opt / -iname 'firefox_binary.py' You can get additional information about the debug options like this: find -D help Another thing to check is whether something is getting fooled by an incorrect st_nlink count on a directory. Try passing the option -noleaf. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?47261> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/