Определение проблемы: я перенес файл tar.gz с компьютера Linux в раздел Windows. Раздел Windows смонтирован с сервером Linux как cifs.
ОС: Red Hat Enterprise Linux Server, выпуск 5
Симптом:
После того, как процесс копирования будет успешным, выполните проверку целостности с помощью gunzip -t, и процесс получит следующую ошибку:
gunzip -t Backup-28--Jun--2011--Tuesday.tar.gz
gunzip: Backup-28--Jun--2011--Tuesday.tar.gz: invalid compressed data--format violated
А дальше пытался распаковать (tar -xvzf
), и процесс также не удался.
Похоже, файл не был правильно передан в двоичном режиме. Возможно, вы сможете заставить его работать с unix2dos Backup-28--Jun--2011--Tuesday.tar.gz
, но если нет, вам придется попробовать передать его снова, убедившись, что он использует двоичный режим.
Способ 1
Пытаться:
sudo apt upgrade
Если нет обновляемых пакетов, извините. Если есть, и одним из них является gunzip, продолжайте. Я рекомендую всегда запускать обновление пакета, так как оно может решить множество ошибок.
Способ 2
Посмотрите, сможете ли вы найти другую программу в Интернете. Если у вас есть кабель или какой-то Wi-Fi, подключенный к вашей машине с Red Hat Enterpise, вы можете использовать lynx
sudo apt install lynx
Вывод
У меня была такая же ошибка, и я по-прежнему не могу найти решение, есть несколько способов решить проблему, но я предлагаю поискать в Интернете более подробную информацию.
Надеюсь, это помогло! Я не гарантирую, что это сработает, но просто говорю вам несколько предложений.
Контрольная сумма исходного и конечного файлов - хорошая идея.
Чтобы получить более точное представление о том, что такое повреждение, вы можете побайтовое сравнение с cmp -l source.gz dest.gz
; Также интересно, отличается ли количество байтов (ls -l
).
Вот еще один небольшой инструмент для анализа, который расскажет вам, как один из файлов мог быть поврежден. Файл zip или gzip достаточно большого размера будет иметь почти равномерное распределение байтов. Ниже приведен сценарий Perl, который будет гистограммать файлы. Файлы zip и gzip, которые были повреждены при передаче в режиме ASCII, будут иметь необычную частоту возврата каретки и новой строки, например частоту или считать вдвое больше нормы, или ноль, или и то и другое. (Я видел разные FTP-серверы или клиенты для разных манипуляций, например, добавление NL после CR или удаление CR из CRLF, или превращение каждого NL в CR, или наоборот. Все это нарушает частоту символов, как я описал. )
Сохраните это как hist.pl
и запустить его с perl hist.pl *.gz
; глядя на частоты в распределении байтовых значений, вы узнаете, делала ли передача что-то вроде удаления каждого CR или добавления CR к каждому LF и т. д.
#!/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;