TAR ERROR

[Nobody's Hero]

OK, I thought I knew tar by now.

I have to tar up a .depot file from one box (to Tape) and extract it on another. Cant ftp because of different network. I ran "tar -cvf /dev/rmt/0m 'filename'.

Then on the target:

tar -xvf /dev/rmt/0m .

I get the following error:

tar blocksize = 2
directory checksum error.


Is this a mismatch with tar versions?

[Judy Traynor]

It could be a tape device problem (different densities?)

try changing the blocksize to -b 20 in your command line.

[Steven E. Protter]

tar version mismatch can cause this.

Also if the directory struture is changing during extraction or isn't consistent between the two machines these things can happen.

I always try to tar and extract at the same relative location to root to prevent this from happening.

Its also possible that the tar file itself is corrupt and you need to tar it again.

tar tvf /dev/rmt/0m

What does that do? Follow the respnse, perhaps try tvf on a different system.

Tape drive problems can definitely cause this Robert.

Hope you are well.

Have a good day.

SEP

[Bill Hassell]

Are these both HP-UX systems? As mentioned, tar is far too primitive to understand different blocksizes. If the target machine is HP-UX, you can use pax to extract the files from tar as pax understands blocksizes. If they are both HP-UX, use fbackup. It's more reliable.

[rmueller58]

I would find a middle man ftp server to avoid the tape crapola.

I use a little 3com daemon on my PC to move files from inside our firewall to a web server in our DMZ rather then eff with a tape.

I would also use fbackup to backup the file,

fbackup is much more portable between HP/UX systems..

fbackup -f /dev/rmt/0m -d /pathtofile/filename

then restore when frecover

frecover -xFvi filename -f /dev/rmt/0m
from the tape..

Just a thought IF you must use a tape.

[Elmar P. Kolkman]

Make sure your tape is rewinded before writing the tar to it:
# mt -t /dev/rmt/0mn rewind

Then write your data (with specified block size to rule out any problems related to that):
# tar cvbf 20 /dev/rmt/0m 'yourfiles'

Test the tape on the machine it was written
# tar tvf /dev/rmt/0m
(It should report blocksize=20, otherwise you could specify it again)

On the other machine, you can test the tape again, or start restoring immediately:
# tar xvbf 20 /dev/rmt/0m

Also make sure you don't accidentally use the wrong tapedrive. I've had that problem too, with tapedrives hidden in the 19" racks, out of sight... You can test it by unloading/ejecting the tape from the command line:
# mt -t /dev/rmt/0mn offl