Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Problem definition: I transferred a tar.gz file from a Linux machine to a Windows partition.The Windows partition has mounted with the Linux server as cifs.

OS : Red Hat Enterprise Linux Server release 5

Symptom:

After the copy process is successful, doing an integrity check with gunzip -t and the process get the following error:

gunzip -t Backup-28--Jun--2011--Tuesday.tar.gz

gunzip: Backup-28--Jun--2011--Tuesday.tar.gz: invalid compressed data--format violated

And further tried to untar (tar -xvzf) and the process as well is failed.

share|improve this question
    
Did you try checksumming the file at the source and at destination ? –  Stephane Jun 28 '11 at 8:11

2 Answers 2

Checksumming the source and destination files is a good idea.

To get a more specific idea of what the corruption is, you could do a byte-by-byte comparison with cmp -l source.gz dest.gz; also of interest is whether the byte count differs (ls -l).

Here's one more little analysis tool to tell you how one of the files may have been corrupted. A zip or gzip file of reasonably large size will have an almost uniform distribution of bytes. Below is a perl script that will histogram files. zip and gzip files that have been corrupted by ASCII mode transfers will have unusual frequency of carriage returns and newlines, e.g. frequency or count twice the norm, or zero, or both. (I've seen different FTP servers or clients to different mangles, e.g. adding NL after CR, or deleting CR from CRLF, or turning every NL into a CR, or vice versa. These all disrupt the character frequency just as I have described.)

Save this as hist.pl and run it with perl hist.pl *.gz; looking at the frequencies in the distribution of byte values will tell you whether a transfer did something like deleted every CR, or added a CR to every LF, etc.

#!/usr/bin/perl -w
use strict;

die "filename arguments expected\n" if ($#ARGV < 0);

foreach my $filename (@ARGV) {
    if (!open IN, "<$filename") {
    warn "can't open '$filename'\n";
    next;
    }
    print "$filename\n";
    binmode(IN);
    my @hist = ();
    my $total = 0;
    while (read IN, my $buf, 1024) {
    foreach my $octet (unpack "C*", $buf) {
        $hist[$octet]++;
        $total++;
    }
    }
    close(IN);

    for (my $i = 0;  $i < 256;  $i++) {
    my $count = $hist[$i] || 0;
    my $p = sprintf("%.5f", $count/$total);
    print "[$i] $count $p\n";
    }
    print "total $total\n\n";
}
exit 0;
share|improve this answer

It sounds like the file may not have been properly transferred in binary mode. You might be able to get it to work with unix2dos Backup-28--Jun--2011--Tuesday.tar.gz, but if not, you'll have to try transferring it again, making sure it uses binary mode.

share|improve this answer
    
Dtbarne, I tried unix2dos conversion but no luck :-) ,still the same error is returning... We are transferring files from 20 different servers to this share, Out of this three files having this problem! –  Arunjith Jun 28 '11 at 6:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.