tail -c 1 /dev/mtd3 hangs (v1.1.3)

[Rob Landley]

On Thursday 22 June 2006 3:31 am, Steven Scholz wrote:
> Looks like sbuf.st_size is 0 for devices. So always calling
>
> 	lseek(fd, 0, SEEK_SET);
>
> is not a good idea. tail_read() gets called again and again.

http://busybox.net/downloads/patches/svn-10884.patch

That was added so tail -f would follow truncated files.  The kernel is saying 
this file is eternally truncated, so it keeps triggering.  Ultimately, the 
problem is in the kernel, but in theory this shouldn't trigger unless you 
chose -f.

> How about using lseek() only for real files, i.e. (st_size > 0) and
> (st_rdev == 0) ?

Or using lseek() only for follow?

> What do you think of
>
> static ssize_t tail_read(int fd, char *buf, size_t count)
> {
>         ssize_t r;
>
>         off_t current,end;
>         struct stat sbuf;
>
>         if (fstat(fd, &sbuf) < 0) {
>                 bb_perror_msg("fstat");
>                 status = EXIT_FAILURE;
>                 return 0;
>         }

If we can't stat the thing then the read is probably about to fail.  Besides, 
we can't do worse than stat returning an insane result but not considering it 
an error, which is apparently what the kernel's already doing for your mtd.

>         if ( (sbuf.st_size > 0) && (sbuf.st_rdev == 0) ) {
>                 end = sbuf.st_size;
>                 current = lseek(fd, 0, SEEK_CUR);
>                 lseek(fd, end < current ? 0 : current, SEEK_SET);
>         }

Makes the code bigger.  Lemme think about how best to fix this...

Rob
-- 
Never bet against the cheap plastic solution.