Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request From: stanonik@nprdc.navy.mil (Ron Stanonik) Newsgroups: comp.sys.sun Subject: cartridge tapes and 126b Keywords: SunOS Message-ID: <5016@brazos.Rice.edu> Date: 15 Feb 90 17:15:12 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 62 Approved: Sun-Spots@rice.edu X-Sun-Spots-Digest: Volume 9, Issue 43, message 2 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