Hello,
newer grep versions do "lseek (fd, cur, SEEK_HOLE)"
but that does not always work as expected,
at least not for ext4 for kernel < 3.1.
This can cause weird results when using a newer grep
for files on ext4 with kernel < 3.1.
Our (SUSE) kernel developers found and analyzed that issue.
Here some excerpts from their mails:
----------------------------------------------------------------------
homer:/usr/local/src/kernel/linux-3.x.git # grep master xx
Binary file xx matches
homer:/usr/local/src/kernel/linux-3.x.git # split -n 2 xx
homer:/usr/local/src/kernel/linux-3.x.git # grep master xaa
CONFIG_LOCALVERSION="-master"
homer:/usr/local/src/kernel/linux-3.x.git # grep master xab
homer:/usr/local/src/kernel/linux-3.x.git #
it doesn't like the first 2000 lines of .config (xx),
but does like both halves.
Made sure by adding that line to xab.
homer:/usr/local/src/kernel/linux-3.x.git # grep master xaa
CONFIG_LOCALVERSION="-master"
homer:/usr/local/src/kernel/linux-3.x.git # grep master xab
CONFIG_LOCALVERSION="-master"
I could reproduce it.
Now grepping the grep code, I found that it checks the binary
also by looking at the hole in a file:
/* Look for a hole after the current location. */
off_t hole_start = lseek (fd, cur, SEEK_HOLE);
if (0 <= hole_start)
{
if (lseek (fd, cur, SEEK_SET) < 0)
suppressible_error (filename, errno);
if (hole_start < st->st_size)
return TEXTBIN_BINARY;
}
And hole_start returns 32768 instead of an error or the end of file.
The reason is that ext4 of SLE11 doesn't support SEEK_HOLE,
it just ignores the flag and returns the current position as is.
----------------------------------------------------------------------
"SLE11" is "SUSE Linux Enterprise 11" which has kernel 3.0.
Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
