Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: zwicky@erg.sri.com (Elizabeth Zwicky)
Newsgroups: comp.sys.sun
Subject: Re: Mystical Parameters for 8mm Drive Sought
Keywords: Miscellaneous
Message-ID: <1348@brchh104.bnr.ca>
Date: 18 Jan 91 22:52:33 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 21
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n14, Replies: v10n19 v10n23 v10n24
X-Sun-Spots-Digest: Volume 10, Issue 24, message 14
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <1333@brchh104.bnr.ca> ziegast@eng.umd.edu (Eric W. Ziegast) writes:
>The "mt eom" command does not work under SunOS 4.*.*.  The fault is on the
>part of the Sun st device driver.

Either this is false, or I am subject to persistent hallucinations of the
most peculiar sort; I've recently been doing data collection from our dump
tapes with a program that starts by doing an "mt eom", and it's worked on
at least two of our drives, and on over a dozen different tapes. Perhaps
they mean not SunOS 4.*.* but SunOS 4.0.3, since we run 4.1, and we did
have hangs on attempts to fsf past eom previously (using different drivers
on different Suns on a different version of the OS, so I'm not willing to
swear to the identity of the critical factor).

The fault that I do know of in the Sun 4.1 st device driver is an
irrational devotion to the concept of writing an eof mark when a device
that has been opened for write is closed. This makes trying to write table
of contents files at the beginning of a tape tricky at best; the old trick
of moving the tape before the close no longer works, and you get erroneous
eofs and a very unhappy tape.

	Elizabeth Zwicky (zwicky@erg.sri.com)