bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #47261] find produces two different results for the same command


From: James Youngman
Subject: [bug #47261] find produces two different results for the same command
Date: Fri, 26 Feb 2016 12:38:37 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]