On Mon, Apr 30, 2012 at 09:57:16AM -0400, Chet Ramey wrote:
> Bash reads 128 characters at a time and uses lseek to move the file pointer
> back to the last character `read' consumes. The negative offset to lseek
> causes some kind of problem, but it doesn't return an error. When bash
> goes back for more, it gets short reads and incomplete data.
>
> It's a kernel bug apparently introduced in 3.2. It doesn't require bash
> to test.
>
> (I guess it was debian:
> http://lists.debian.org/debian-kernel/2012/02/msg00874.html . The original
> report thread is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659499 .)
That's... interesting, since I got exactly the same failures on a stock
Debian 6.0 system (bash 4.1.5, kernel 2.6.32-5-686).
Is this something that was broken until kernel 3.0 or 3.1, then fixed
briefly, and then broken again? (I haven't used a Linux 3.x kernel yet.)
Since this fails:
#include <unistd.h>
main() {
char s[20];
int n;
while ((n = read(0, s, 20)) > 0) {
write(1, s, n);
}
}
I cannot consider this anything but a kernel bug. Successive reads
from an open file descriptor without any intervening close() or lseek()
should get the full content of the "file". The kernel should be putting
the full set of data into a nonvolatile buffer when such a "file" is
opened, and only releasing that buffer when it's closed.
