maemo.org Bugzilla – Bug 3968
grep -r can output corrupt data in error message if file cannot be read
Last modified: 2010-02-11 15:27:00 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. Run "grep -r blahblah /etc/alternatives" (you can also try on the whole /etc
grep should write error messages of the form:
grep: /path/to/filename: No such file or directory
grep: /path/to/filename: Permission denied
In error messages, /path/to/filename is often corrupt and contain random bytes.
With the above command, the output starts with (in hexa):
00000000 67 72 65 70 3a 20 48 f1 04 3a 20 4e 6f 20 73 75 |grep: Hñ.: No su|
00000010 63 68 20 66 69 6c 65 20 6f 72 20 64 69 72 65 63 |ch file or direc|
00000020 74 6f 72 79 0a 67 72 65 70 3a 20 2f 65 74 63 2f |tory.grep: /etc/|
48 f1 04 correspond to corrupt data.
always (when the problem occurs, the same command yields the same output;
corruption occurs only under some conditions, but the problem is always
reproducible with /etc, and even /etc/alternatives).
Reproducible when grepping whole /etc, but there's an easy workaround:
grep blahblah $(find /etc/alternatives -type f)
(for me the grep -r actually messed up the XTerm font and as there's no
"reset", I lost that session, so keeping as normal severity.)
Doesn't seem to occur with Fremantle Busybox (v1.10), so setting TM for
Fremantle. As its /etc/ contents differ, cannot be sure about it working there
though, do you have some other test-case besides /etc?
Any non-readable file seems to trigger it. Try for example creating a
directory containing a dangling symbolic link and/or a regular file without
~ $ mkdir /tmp/greptest
~ $ echo foobar > /tmp/greptest/foobar.txt
~ $ chmod 000 /tmp/greptest/foobar.txt
~ $ ln -s /no/such/file /tmp/greptest/
~ $ grep -r foo /tmp/greptest/
grep: /tmp/greptest/: No such file or directory
grep: /tmp/greptest/: Permission denied
Created an attachment (id=1081) [details]
use actually initialised filename data in error messages
Looking at the source, the bug/fix seems obvious (attached). Note: I haven't
actually built/tested this (my scratchbox is broken at the moment).
(In reply to comment #3)
> Any non-readable file seems to trigger it. Try for example creating a
> directory containing a dangling symbolic link and/or a regular file without
> read permissions:
> ~ $ mkdir /tmp/greptest
> ~ $ echo foobar > /tmp/greptest/foobar.txt
> ~ $ chmod 000 /tmp/greptest/foobar.txt
> ~ $ ln -s /no/such/file /tmp/greptest/
> ~ $ grep -r foo /tmp/greptest/
> grep: /tmp/greptest/: No such file or directory
> grep: /tmp/greptest/: Permission denied
Seems to work fine (doesn't produce any strange chars) in Fremantle.
(In reply to comment #4)
> Looking at the source, the bug/fix seems obvious (attached).
In Busybox 1.10.2 the filename given for the fopen() & error message match.
Thanks! Setting as Fixed in Fremantle.