On Sat, 29 Jan 2005, Eric Schnoebelen wrote:

> 	I've composed the rest of the reply intermingled with
> the original posting below.
>
> - ---------- Forwarded message ----------
> - Date: Wed, 26 Jan 2005 00:16:18 +0200 (IST)
> -
> - Hi, I have strange problems again:
> -
> - st0 is a qic-150, it has file1 file2 file3 on it, in this order,
> - put on by tar, on the same system. When I try to read any back,
> - besides the first file, I get nothing from tar until the third
> - (!!) try. See below:
>
> 	Did you put the three tarballs on the take using this
> form:
>
> 	tar cf /dev/nrst0 <file list>;
> 	tar cf /dev/nrst0 <file list>;
> 	tar cf /dev/nrst0 <file list>;

Yes, I did:

export TAPE=/dev/nrst0
tar cf file1
tar cf tile2
tar cf file3

each archive contained just one file. At the end of this, mt status 
indicated file position 4 (?).

> - I issue commands like:
> -
> - > export TAPE=/dev/nrst0
> - > mt rewind
> - > mt status
> - SCSI tape drive, residual=0
> - ds=3<Mounted>
> - er=0
> - blocksize: 512 (0, 0, 0, 0)
> - density: 0 (0, 16, 15, 5)
> - current file number: 0
> - current block number: 0
> - > tar tv
> - file1
> - > mt fsf
> - > tar tv <- nothing! $? is 0!
> - > tar tv <- nothing! $? is 0!
> - > tar tv <-this time it works ?!!
> - file2
> -
> - I tried this several times. What could cause this ? And why does
> - tar not return an error code anyway ?! mt status after fsf shows
> - file 1 block 0 (as it should). Is this a tar problem ? A mt
> - problem ? A st problem ? A faulty drive or driver could not cause
> - this (tar should notice a short archive and complain, no ?) so
> - I think it's a tar problem.
>
> 	I think you're running into correct operation.

It seems to be so, but imho tar MUST return an error condition when 
reading an empty archive.

> 	Basically, the magnetic tape driver drops two filemarks
> on device close to mark end of tape.  So, you've written a
> tar archive to the tape device with tar, and it closed the device.
> Two filemarks were written.

Ah, now I understand. So mt status should show N+1 in the file count 
after this, where N is the number of files written ?

> 	Then you wrote another tar archive to the tape, with out
> backing up over the second of the two file marks.  And again
> with the third..
>
> 	So, your tape looks like this:
>
> 		tar archive
> 		file mark
> 		file mark
> 		tar archive
> 		file mark
> 		file mark
> 		tar archive
> 		file mark
> 		file mark
>
> 	When reading, tar just reads up to the "magic" EOF
> marker that tar emits on writing. This doesn't correspond to the
> EOF marker that is written by the tape device.  So, you get to
> do ``mt fsf 1'' to get to the first file mark after the tar
> archive.
>
> 	Your second read, tar reads EOF immediate, and exits
> with success.
>
> 	I'm not sure why your third read isn't picking up the
> next tar archive, but I'd guess it's because the tape hasn't
> advanced past the filemark yet..
>
> 	You should be writing these tapes in the following
> fashion:
>
> 		tar cf /dev/nrst0 <files>
> 		mt bsf 1
> 		tar cf /dev/nrst0 <files>
> 		mt bsf 1
> 		tar cf /dev/nrst0 <files>
>
> 	That way, the tape will look like:
>
> 		tar archive
> 		file mark
> 		tar archive
> 		file mark
> 		tar archive
> 		file mark
> 		file mark
>
> 	Which is what you want it to look like..
>
> - Also, tar always leaves the tape at the current file, last block.
> - Reading the tape with dd leaves the tape at the start of the next
> - file, block 0.
>
> 	See the discussion above.  Tar(1) reads until it finds the
> end of archive marker, and quits.  Since tar works on many
> different media types (including regular files) it doesn't
> really have much in the way of tape handling in it..
>
> 	dd(1) reads off the tape in the block size you
> specify. It reads until it encounters an EOF marker (in this
> case, a file mark.)
>
> -               Additionally, if I use /dev/rst0 instead of
> - /dev/nrst0 with tar, it rewinds and exits normally without
> - extracting anything! This is dangerous!
>
> 	Depending on the tape position at the begining of the
> command, ``tar xf /dev/rst0'' should read the current tar
> archive, and then rewind the tape device upon close. (this is a
> semantic of the rst0 device, rewind on last close.)

You seem to be right but I'd like to know why tar does not return an 
error condition on empty input from tape. This is bad, it means I can't 
check with a script whether tar succeeded or not.

Also my problems seem to be related to the 'early warning' behavior 
explained in the mt(1) manual. Maybe the st driver does not return EIO 
if not in early warning mode ?

I tried to write an entire tape with zeros to see how much extra 
capacity I can squeeze in and then it did get an EIO at the end (as it 
should).

thanks,
Peter