Jon LaBadie <jon AT jgcomp DOT com> writes:

> Quibbling perhaps, maybe it does not say amanda will break,
> but it seems quite explicit in what it wants:
> 
>     tapedev "..."  # the no-rewind tape device to be used

True, but I assumed that this was just convention.  amanda when
dumping has a 'open tape drive once, write, write, close' mentality,
avoiding trusting the OS to do the right thing with multiple
open/write/close, open/write/close.  So I expected the other programs
to behave the same way.  AFAIK, it's only amverify that is an issue.

But you are right; the example is arguably clear.

> Which is one reason why your choices 2 & 3 are such good choices.
> And so easy to implement portably in the local environment in a crontab.
> 
>    2 3 * * 1-6   amdump DS1 ; mt offline

Sure, that's fine.  I don't want to do that because I do dumps Tuesday
to Saturday mornings, and on Sunday morning run amverify on the tape
from Saturday morning.  (I once had a tape drive that scrambled bits
with no warning; I could amrestore them off and gzip would fail to
decompress.  A weekly amverify is my check that this isn't recurring,
in the too-frequent case I don't periodically choose a file at random
and get it back.)  So in that case I suppose I should do

  2 3 * * 1-6   amdump DS1 ; mt -f /dev/rst0 rewind

Perhaps NetBSD is buggy not to interpret 'mt rewind' as ending a
mount session, but that's a tough call.

    Greg Troxel <gdt AT ir.bbn DOT com>