3

This has happened to me twice (EDIT: many times and I can replicate it) now. I'm working on a Raspberry Pi, looking for a file I already know exists and so I type this command:

sudo find / -iname 'firefox_binary.py'

The first time I type it, it runs without errors, but it doesn't find the file. However, when I run the same command only seconds later, it finds it.

It's the same command, run in the same terminal window, under the same path, on the same system, with the same file structure, with only a few seconds separating the first run from the second run. How is this result even possible?

Improve this question
15
  • 1
    Can you reproduce this behaviour? If so, how?
    – FelixJN
    Feb 24, 2016 at 21:18
  • That doesn't sound right - execute it under strace?
    – tink
    Feb 24, 2016 at 21:27
  • 2
    What a nice mystery... Did you notice that the second search needs much longer to complete? What does mount say both times (just add it to the line with a semicolon)?
    – Murphy
    Feb 24, 2016 at 21:55
  • 1
    Here's the strace results from the first and second search respectively: lenschulwitz.com/find1.txt lenschulwitz.com/find2.txt mount result on the way...
    – schulwitz
    Feb 24, 2016 at 22:00
  • 1
    The upstream bug report (in case people want to follow it) is at savannah.gnu.org/bugs/?47261
    – James Youngman
    Feb 26, 2016 at 12:44

2 Answers 2

Reset to default
1

Given the findings above, as workaroud you could try to either restrict the search to /usr

sudo find /usr -iname 'firefox_binary.py'

or skip /sys in one of the following ways, whatever suits your use case best:

sudo find / -mount -iname 'firefox_binary.py'

sudo find / -not -path '/sys/*' -iname 'firefox_binary.py'

Another, but IMHO more ugly workaround would be to try triggering the population of the problematic dir(s) before searching, e. g. with

ls /sys/kernel/debug/tracing/options

or

cat /sys/kernel/debug/tracing/options/<some_file>

or whatever it takes.

I also suggest you file a bug report with the maintainers of your find (probably either busybox or findutils). I think find shouldn't just exit the recursion in this case, and at least it mustn't without an error message.

Improve this answer
1
  • Thanks for the suggestions. It's not a major problem, as I can just type the command twice, but it's so unusual to see a built-in linux command just completely fail like this without any errors, that I thought I should report it here. I've filed a bug report, thanks for the link.
    – schulwitz
    Feb 25, 2016 at 19:25
1

This is a real bug found in find version 4.4.2, but the bug has been fixed in find version 4.6.0.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .