On Fri, 28 Jan 2005, Dan LaBell wrote:

>> Hi list, I posted this message a few days ago and there was no reaction.
> Perhaps, few people have tapes these days, compared to tv cards, sounds 
> cards, dual cpu, and dvd...

You are right.

> Maybe try, cpio , pax, or dump, see if anything changes.  Your tar contains 3 
> files right? Not you have have 3 tars containing 1 file each on the tape?

I have 3 tars containing one file each.

> Can you use dd to copy the tar off the tape to disk, then examine the tar 
> file for completeness. If its a gzipped tar you wouldn't need the exact size, 
> as gunzip will ignore trailing garbage.   You could also pipe dd into tar... 
> but if dd works and tar by itself doesn't my wild guess would be block sizes.

The tar files are complete. Even tar finds them, but only the *third* 
time (try 3 times, without moving the tape, find nothing twice, 
successfully !!! (there goes your backup) then the third time find it, 
but still leave the tape on the last block). Using dd and other tools 
seems to work correctly.

> <...>
>> dd leaves the tape at the start of the next file, block 0. Additionally, 
>> if I use /dev/rst0 instead of /dev/nrst0 with tar, it rewinds and exits 
>> normally without extracting
>
> I haven't used tapes in maybe 10 years, and that was on sunos, but I seem to 
> remeber 1 device was configured to always rewind on close() , and other ones 
> not...  like r for tape
> meant rewinding st0 not 'raw' , i think it was an historical unix thing not 
> just a sun thing... but its been a while.

The manpage for tar and mt says that nrst0 is the non-rewinding tape 
device, and my experience confirms this. I used nrst0 as tape device for 
my trials. If I said otherwise then I made a mistake, I checked the 
script, and it was nrst0.

Additional information that may help someone:

When reading files with successive dd's the EOM mark was not found, if 
the block size was default (512). It was found, if the block size was 
not set to default (dd bs parameter). If the block size was 512 then the 
dd always returned ok, with no EIO faults (see st manpage wrt early 
warning recognition). It would be interesting to strace the tar and dd 
tape operations and see what is really returned.

What is the equivalent of strace on netbsd ? ktrace/kdump ?

thanks,
Peter