Gene Heskett <gene_heskett AT iolinc DOT net> writes:

> To get around this, one would assume that amcheck has already been 
> run, and that the correct tape for tonights session is indeed 
> loaded into the drive,

This doesn't work when you have to write to more than one
tape. Sometimes you do not even know in advance how many tapes will be
needed.

> a: rewind tape
> b: dd tape label to scratch file, don't forget the 'bs=32k'
> c: rewind tape
> d: turn compression off by whatever method
> e: dd 10 megs or more worth of /dev/zero to the drive, causing it to
>       flush its buffers.  This will cause that compression flag to be 
>       reset permanently on this tape.  Using bs=32k of course
> f: rewind tape
> g: dd the scratch file back to the tape to restore the proper label.

For my DLT drives writing 32k is sufficient.

The taper rewrites the label anyway, so the only additional step is to
have the taper do the mt call before writing the label back.

Two options:
- do the ioctl internally. This might be machine-specific ...
- call external mt. This means taper has to close the tape fd, call the 
  external program and the reopen the tape. This is against taper's 
  race-avoiding principles.

But when you handcraft this by any workaround like you proposed, there
are even more races possible. (Like something migt change the tape
beetween your amcheck and yout script-erasing.)

So I see these two options which both have their drawbacks.

        Sven