Paul Eggert wrote: > On 07/31/2012 11:43 AM, Jim Meyering wrote: >> It seems a little too far-fetched >> even for me. > > Hah! I never thought I'd get you to say *that*! > > I suppose you're right. As far as POSIX-conformance goes, > apps are not required to work "correctly" in the presence > of mount+unmount syscalls by other processes, and as > a practical matter it is a rare case where it'd matter. > Still, it'd be nice to avoid the extra complexity, if > we could. > > It's too bad that there's no reliable way to tell whether > SEEK_HOLE really works without writing to the file system > in question (which'd be even worse). > >> I do not like it when grep -r mysteriously hangs and makes >> my system run out of memory. This really does affect me a couple >> times per month, at least. > > This can happen when files look like text for the first 32 KiB, > but have big holes later. If that's the problem, how > about the following patch? > >>From ca6e5ec860cf5a2af060e2a5c8c53d9004ddc131 Mon Sep 17 00:00:00 2001 > From: Paul Eggert <[email protected]> > Date: Tue, 31 Jul 2012 15:37:40 -0700 > Subject: [PATCH] grep: switch to binary mode when encountering binary data > anywhere > > * src/main.c (buffer_is_binary): New function. > (file_is_binary): Use it. Test for binary data anywhere in the > file, not just at the start; and when it's encountered, switch > to binary mode.
Thanks for writing that, but the cost of traversing each buffer one more time via the added memchr seems like it would be disproportionately high for this infrequently-seen problem. Maybe waiting for more wide-spread SEEK_HOLE/SEEK_DATA support is better after all.
