Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.unix.questions
Subject: Re: Can't cat tape- big blocks?
Message-ID: <829@adpplz.UUCP>
Date: 21 Jun 91 16:33:39 GMT
References: <803@adpplz.UUCP> <1991Jun14.094822.7029@prl.dec.com> <14433@dog.ee.lbl.gov>
Distribution: usa
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 46

Here I am again, and thanks to all who replied; we used dd and it works
just like you said.


>In article <1991Jun14.094822.7029@prl.dec.com> boyd@prl.dec.com
>(Boyd Roberts) writes:
>>No, never do that.  With 9 track tapes you must do I/O that will
>>ensure that the _whole_ tape block will be read. ...

In <14433@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:

>It seems to me that the tape driver should return an error if you
>ask for 1K and the tape drive reads 10K.

Ummmm. Please confine flames to email. (Takes deep breath. Prepares
to meet ancestors.)

How about having the tape driver return the data? You know, just like
the disk driver, and the terminal driver, and the ethernet driver,
and the printer driver. I _never_ told the system what blocksize my
files are, and when I read them I get _every single byte_.  When we
went to our unix introduction class (not _training_. We don't have
time for _training_.) the teacher gave us the religious incantation
that "everything's just a byte stream, and they're all just the same".
Which is why we screwed up in the first place.

Streamers need fixed _buffering_ independent of block size, that ought
to be a function of the driver or the controller. If you don't want to
have permanent large buffers in the tape driver or controller, you could
use the P*ck idiom for setting up the tape drive before a read or write
process (effectively an ioctl that defines block size, buffering, density
and any other exciting features) instead of the unix naming convention.

Vast perverse heresy: If you built a streams tape driver, you could
handle multiple volumes and arbitrary kinds of labeling, independently of
your process! just like the hype says.


Like I said, flames to email. I promise to grovel with satisfactory
abject humility.


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp