Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

tar: directory checksum error 1

Status
Not open for further replies.

fmiller

IS-IT--Management
Oct 9, 2000
26
0
0
US
I received this message while attempting to restore a group of archived files. Is this caused by a bad backup, or is there something else going on here? It had been compressed prior to being stored on tape. I used tar to copy the comressed file off the tape into a temporary directory, uncompressed it, then used "tar xvf tarfilename.tar" to restore it. It restores maybe twentyfive or so files, then dies with this directory checksum error message.
 
try

dd if=tarfilename.tar bs=1024|tar tvf -

change blocksize try bs=512, bs=10k etc.
 
Thanks for the info. I tried it with several different block size settings as you suggested - no difference. It still dies at the same place with the same error message. Guess it is a bad backup.
Frank
 
How exactly were the files backed up (i.e. devices and commands used)?

It seems odd to me that the uncompress would succeed (implying that the backup on tape was actually good) but the subsequent tar would fail. Or does compress not do much error checking? Annihilannic.
 
It would appear that the original TAR was probably bad, but it is also possible that the compress could have clobbered it.
I know that TAR puts a 512 byte block header out first and any problem there will give the directory checksum error.

The only filechecking on the original would have been if you had done a tar tv. This is the reason that microlite and lone-tar do so well.
Ed Fair
unixstuff@juno.com
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.
 
I think I found the source of the problem.

The backup script is set up to create a compressed archive of each of two data directories into two separate files on the hard drive, then tar them onto the tape drive. Why the files aren't tarred directly to the tape, I don't know.

I happened to notice a core file in the one data directory with the same time and date as the compressed file for that directory. When one of the directories gets compressed, the file that gets created exceeds the shell's maximum file size (as set by ulimit). So the compression stops right there at the limit. But as far as the script knows, there was a backup file created, so it just continues on and tars it to the tape, leaving me a backup that is junk.

Increasing the value of ulimit (I doubled it), and removing a lot of old junk files from the directory lets the script operate correctly.
 
Thanks for that - it's always nice when someone posts a solution that as everyone stumped. Cheers.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top