Subject: Re: mt(1) doesn't report file number?
To: Charles Shannon Hendrix <shannon@widomaker.com>
From: Greywolf <greywolf@starwolf.com>
List: port-sparc
Date: 03/24/2002 23:20:01
Speaking from experience, I can state that "mt st" giving the tape
position (record number within a file and file position on tape) is
more than just "nice"; in fact, I can't ever remember a time, either
before or outside of NetBSD, in which it was actually broken!  It's
darned useful, really...

In its defense, the code inside the mt program, the mtio interface and
the various tape drivers have *always* stated regarding the error
register and the drive status register:

	These register values are highly prone to error and should not
	be relied upon.

[in particular, the ds and er would change positions between little-
endian large address machines (i.e. VAX) and big-endian machines (i.e.
Sun).]

Indeed, any program doing tape I/O should be keeping track by itself as
to where in the tape it is, probably, but the fact that PEOPLE don't
always know where the tape is positioned does remain a reality, and
that's actually one of the things about mt under NetBSD that bugs
me.  The other one is the double-file-mark problem that rears its head
-- or used to -- on the 8mm drives.  I don't think I've run into it
for a while, maybe that was fixed.

One thing I think I'd like to see, and this should be relatively trivial
once the file (and record?  Please?) position is implemented, is the
implementation of the "asr" and "asf" (absolute space file/record)
commands under mt.

On Sun, 24 Mar 2002, Charles Shannon Hendrix wrote:

# Anyway, maybe it is a bit silly, but the change to mt will have a positive
# effect, because there is one serious backup utility that does depend on
# tape position: a system administrator.

Bingo.  We cannot forget the sentient element.

				--*greywolf;
--
NetBSD:  Got source?