🚀 go-pugleaf

We ran into an apparent bug which occurs when reading cartridge tape files
whose size is a multiple of 126 blocks.  We've seen this on sun4's running
sunos4.0.3 (and haven't checked sun3's or sun386's).

If the read is performed using a buffer bigger than 126 blocks (eg,
read(fd, buf, 127*512)), and the tape file size is a multiple of 126
blocks, then eof is skipped (ie, read never returns 0) and read read's
into the next file.

Is this a bug, or is there something significant about 126 blocks; ie, one
should never use a buffer bigger than 126 blocks?  126b does seem to be a
popular number when manipulating cartridge tapes.

Thanks,
Ron Stanonik
stanonik@nprdc.navy.mil

Here's a little program to demonstrate the problem.  It writes
two files to tape, the first is cnt blocks and second is 1 block.
Then it reads the first file 512 blocks at a time until eof.
main(argc, argv)
	int argc;
	char **argv;
{
	int cnt=20, fd;
	char buf[512*512];

	if (argc == 2)
		cnt = atoi(argv[1]);
	fd = open("/dev/nrst8", 1);
	printf("write(%d)=%d\n", cnt, write(fd, buf, cnt*512));
	close(fd);
	cnt = 1;
	fd = open("/dev/rst8", 1);
	printf("write(%d)=%d\n", cnt, write(fd, buf, cnt*512));
	close(fd);
	fd = open("/dev/rst8", 0);
	while (cnt = read(fd, buf, sizeof buf))
		printf("read=%d\n", cnt);
}

coral[1] ./a.out 126
write(126)=64512
write(1)=512
read=64512
read=512	missed the eof, this is the first block of the 2nd file

coral[2] ./a.out 125
write(125)=64000
write(1)=512
read=64000	saw eof

coral[3] ./a.out 127
write(127)=65024
write(1)=512
read=65024	saw eof

coral[4] ./a.out 252
write(252)=129024
write(1)=512
read=129024
read=512	missed eof