Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!decprl!decprl!boyd From: boyd@prl.dec.com (Boyd Roberts) Newsgroups: comp.unix.questions Subject: Re: Can't cat tape- big blocks? Message-ID: <1991Jun14.094822.7029@prl.dec.com> Date: 14 Jun 91 09:48:22 GMT References: <803@adpplz.UUCP> Sender: news@prl.dec.com (USENET News System) Distribution: usa Organization: Digital Equipment Corporation - Paris Research Laboratory Lines: 29 Nntp-Posting-Host: prl313.prl.dec.com In article <803@adpplz.UUCP>, martin@adpplz.UUCP (Martin Golding) writes: > We got a 9 track tape in tar format, with 10k blocks. It's from a BSD type > system (at least, the tar headers match my sun manuals and tar from > the Motorola doesn't work). The only tape drive we have is on one of > the Motorola boxes, so what we figured was, we'd cat it to a file > on the Motorola box and then rcp or rsh tar the puppy from the Sun. > > When we cat it to a file (cat /dev/r50t >/dir/bigfile), it looks > like we don't get all the data from the tape. We get the same effect > if we rsh cat . No, never do that. With 9 track tapes you must do I/O that will ensure that the _whole_ tape block will be read. Odds on that cat(1)'s blocksize is much less than 10k, and consequently each tape read returns part of the tape block. The tape will be positioned to read the next _tape block_ and the stuff you didn't read is lost. Now, from what I've seen, streamers don't behave like this. But _all_ 9 track UNIX tape drives do. If you find one that doesn't -- it's broken. So you want I/O's that are the same size as the tape block. Use tar directly or: dd if=/dev/r50t bs=10k of=/dir/bigfile Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''