tar - unexpected end of tape message

[Nick Wickens]

Hi All

I am trying to extract a tar archive from a supplier but I am getting end of tape messages whenever I try and list or unload the tape. I can get all of the files off of the tape correctly apart from the last one which always comes up as a short file - Heres the message -

live:/> tar -tvf /dev/rmt/1m
rw-rw-rw- 0/0 475136 Nov 26 09:54 2002 ./TAR/gbdataf1.fme
rw-rw-rw- 0/0 26329088 Nov 26 09:54 2002 ./TAR/gbdataf2.fme
rw-rw-rw- 0/0 11530240 Nov 26 09:54 2002 ./TAR/gbdataf3.fme
rw-rw-rw- 0/0 24993792 Nov 26 09:54 2002 ./TAR/gbdataf4.fme
rw-rw-rw- 0/0 24338432 Nov 26 09:54 2002 ./TAR/gbdataf5.fme
rw-rw-rw- 0/0 3395584 Nov 26 09:54 2002 ./TAR/gbdataf6.fme
rw-rw-rw- 0/0 20480 Nov 25 15:26 2002 ./TAR/gbdataf7.fme
Tar: end of tape
Tar: to continue, enter device/file name when ready or null string to quit.

The last file always extracts as -rw-rw-rw- 1 root sys 18944 Feb 18 11:35 gbdataf7.fme

This is the third such tape from them but before I conclusivly say its their problem does anyone have any further insight.

Have tried extract one two different drives/systems (Both DDDS3).

[Steve Steel]

Hi

tar during backup will write on the next tape.

Probably they are backingup via cron which mails the tape request to root and they have never seen it.

After a while the tar timeout and you have an unfinished shortened file where you are lost.

Customer should check the backup especially for mail and then try using fbackup instead.

Or pipe tar via dd to compress the input


Steve Steel

"Never mistake knowledge for wisdom. One helps you make a living; the other helps you make a life."
-- Sandra Carey

[Chris Wilshaw]

I assume that you've done the usual - clean the drive, check syslog for errors etc.

The file sizes don't look overly large, so I wouldn't expect them to go over 1 tape, so it looks like you've been given a duff tape.

[V. Nyga · Accepted solution]

Hi Nick,

I've problems reading tapes fom SGI because they use variable block sizes.
Try:
dd if=/dev/rmt/1m bs=1024k l tar xvf -

(l is pipe!)

Other suggestion:
They should add one more file, which you don't use.

Regards
Volkmar

[Frank Slootweg]

What is the source system?

The last file is exactly a multiple of the default blocking factor (10KB, 20 blocks). Perhaps that leads to a blocking problem (which, as Volkmar also mentions, is common for non-HP-UX source platforms).

Try:

dd if=/dev/rmt/1m bs=10k conv=sync | tar tvf -

[Nick Wickens]

Volkmar had the solution thanks - This routine had been working fine for the last 5 years and they have admitted that they now create the tapes on PC platforms.

I had tried adjusting the blocksizes on the extracts without success so thanks for the info.