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/
