[TUHS] Determining what was on a tape back in the day

[random832@fastmail.com (Random832)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

On Sun, Nov 19, 2017, at 20:18, Dave Horsfall wrote:
> On Sun, 19 Nov 2017, Ronald Natalie wrote:
>
> [ Tape as a mountable file-system ]
>
> >> So you mount it read-only...
> >
> > Still won’t work.    Seek doesn’t work right.
>
> I don't feel like arguing this, but it most certainly did for me,
> thank you very much (I'm desperately trying to be polite here); a
> modified tape driver, perhaps?  It was quite amusing watching it
> thrash back and forth, until I put it out of its misery.
>
> I think I even mentioned it once, in an issue of AUUGN; all I remember
> now was that the tape had 512-byte blocks, just like the RK-05 from
> which it was presumably DD'd (I wasn't silly enough to try a MKFS).

For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward say
"seeks have their usual meaning", and both drivers provide a 'non-raw'
device which is a block device and (according to the manual) only
supports tapes consisting of 512-byte records - the BUGS section
mentions that the raw device, conversely, does *not* support seeking.

It's not clear exactly what kind of support the block device had for
unaligned read/write/seeks (the mention of "monstrous record gaps" for
small writes suggests it was not seamless), but it seems like it not
being possible to replace whole blocks explicitly is something that
would have been mentioned.

The 'raw' interface itself first appears in V5; The V4 manual does not
mention seeking, but also does not mention "record gaps". The V4 kernel
only has tm as a block device. The V3 manual says seeking does not work,
and describes semantics for reads/writes of less than 512 bytes that are
not mentioned in later versions of the manual.

Modern OSes (Linux and BSD, anyway) do not provide the block device, and
use ioctl for "seeking" (since lseek is an inappropriate interface for
block-level seeking).

On a historical note, it looks like in addition to the original PDP/VAX
drivers, Interdata 7/32 and Tahoe ports also provided "non-raw"
interfaces for those platforms' particular tape devices, whereas the
HP300 port of 4.3BSD did not.