Отправляет email-рассылки с помощью сервиса Sendsay

Recovery RAR

Скачал rar архив ~2G некоторые файлы оказались битыми.
Есть ли какой-нибудь способ выяснить место порчи архива чтобы скачать
именно этот порченный кусок.

Ответить   Sun, 31 Jul 2005 14:59:37 +0400 (#410737)

 

Ответы:

В сообщении от 1122811177 секунд после начала Эпохи Dmitry A.
Kharitonov написал(а):

:) Думаю причина не в битом архиве, а в его не нормальном размере. 2G -
это как раз та граница, когда 32-битные числа со знаком, начинают
становится отрицательными (2G = -1.999999G). Вполне возможно что в
RAR-архивах используются 32-битные числа без знака (тогда допустимый
максимум 4G). Но знает ли об этом программа, которая распаковывает этот
архив?... И вообще поддерживает ли она большие (>2G) файлы?...

Ответить   Konstantin Korikov Mon, 1 Aug 2005 03:02:19 +0300 (#410794)

 

Я же написал приблизительно 2G. RAR поддерживает и большие размеры.
Ну влом мне опять неделю выкачивать этот архив.

Ответить   Mon, 1 Aug 2005 08:42:20 +0400 (#410847)

 

Здравствуйте, Konstantin.

Вы писали 1 августа 2005 г., 3:02:19:

А причина кроется, возможно в wget. У него есть проблема скачивания
файлов больше 2 гб - с этим я уже столкнулся. Решается просто, надо
обновить на текущую версию.

WinRAR supports files and archives up to 8,589 billion gigabytes in size. The
number of archived files is, for all practical purposes, unlimited.
Взято отсюда: http://rarlab.com/rar_archiver.htm
Естественно, 100% такие большие архивы держутся с версии 3.50

С третьей версии:
WinRAR v3.0 Final (дата выпуска 05-15-2002):
WinRAR supports files and archives up to 9,223,372,036,854,775,807
bytes in size, about 9000PB. The number of archived files is,
for all practical purposes, unlimited.

так что, надо смотреть информацию об архиве,- какой версией архиватора
сделан этот архив...

Также помнится были иногда глюки, с ранними версиями разных качалок -
портились файлы, при закачке ими....

у разных старых версий wget по разному вылазили глюки с файлами > 2gb.

Ответить   "Kanogin A.A." Mon, 1 Aug 2005 08:36:56 +0300 (#410848)

 

Здравствуйте, Kanogin.

Вы писали 1 августа 2005 г., 9:36:56:

The

Из справки:
t Протестировать файлы в архиве

Эта команда имитирует извлечение файлов, ничего не записывая в
выходной поток, а лишь проверяя указанные файлы.

Примеры:

Протестировать архивы в текущем каталоге:

rar t *
или для UNIX:
rar t '*'

Можно протестировать архивы во всех подкаталогах, начиная
с текущего:

rar t -r *
или для UNIX:
rar t -r '*'
У меня еженедельная полная копия ~3 Гб. Сжимается RaR'ом
Проблем нет. Хотя - ФАТ не использую.

Ответить   Mon, 1 Aug 2005 09:54:49 +0400 (#410880)

 

в

Тестирую и получаю, что некоторые файлы не совпадают по контрольным
суммам. Как найти место порчи архива?

Ответить   Mon, 1 Aug 2005 14:43:16 +0400 (#411061)

 

Здравствуйте, Dmitry.

Вы писали 1 августа 2005 г., 14:43:16:

rar - ИМХО этого не умеет.Расположение файлов возможно указывать
только при создании файла.

Ответить   Mon, 1 Aug 2005 19:27:06 +0400 (#411247)

 

Понятно. Придётся писать программу.
тема закрыта.

Ответить   Mon, 1 Aug 2005 20:54:00 +0400 (#411318)

 

Здравствуйте, Dmitry.

Вы писали 1 августа 2005 г., 19:54:00:

я делал так:
на удаленной стороне резал кусками и куски считал на md5sum.
соответственно - на своей стороне также.
но у меня доступ по ssh

Ответить   "Kanogin A.A." Mon, 1 Aug 2005 22:15:44 +0300 (#411366)

 

Всё это автоматически делает rsync. Но на сервере-источнике демон
этого сервиса не поднят.

Ответить   Mon, 1 Aug 2005 23:15:53 +0400 (#411396)

 

Ну вот и я говорю же произошла ошибка. Нужно найти место ошибки. Чтобы
исправить.

архив 1.8G

Ответить   Mon, 1 Aug 2005 14:31:56 +0400 (#411070)

 

В сообщении от 1122874616 секунд после начала Эпохи Kanogin A.A.
написал(а):

Вполне возможно. Я сейчас посмотрел у себя:

$ objdump -d /usr/bin/wget |grep [fl]seek
0804a2b0 <fseek@plt>:
8069072: e8 39 12 fe ff call 804a2b0 <fseek@plt>

$ objdump -d /usr/bin/unrar |grep [fl]seek
08049334 <fseeko64@plt>:
804c2da: e8 55 d0 ff ff call 8049334 <fseeko64@plt>

Как видно, unrar поддерживает большие файлы, а wget нет.

Ответить   Konstantin Korikov Mon, 1 Aug 2005 16:19:14 +0300 (#411181)

 

Доброго времени суток, Dmitry.

На раздел с какой файловой системой сохраняли?
Если на FAT/32, то там ограничение на размер файла в ~2G. Для таких
больших файлов нужно использовать NTFS - тогда RAR может быть до 4 ТБ.
Про ext2/3/reiserfs/xfs ничего не могу сказать, так как не знаю их
лимиты...

Ответить   Владимир 'insider' Прохоров Mon, 1 Aug 2005 08:25:55 +0400 (#410845)

 

Здравствуйте, Владимир.

Вы писали 1 августа 2005 г., 7:25:55:

Почитал http://zeus.sai.msu.ru:7000/operating_systems/linux/HOWTO/Large-Disk-HOWTO-7.shtml
и немного не понял... там какие-то странные наименования:

Линукс использует только поля start и length , и поддерживает партиции содержащие
не более 2^32 секторов , т.е. размер раздела ограничен 2 ТиБ. Это в 100 раз больше
чем любой доступный сегодня диск , и вероятно это лимита хватит на следующие
5-8 лет. (Хотя разделы и могут быть очень больших размеров, но в тоже время нужно
помнить что максимальный размер файла в ext2 системе 2 ГиБ)

DOS использует поля begin и end и использует сервисы BIOS (Int 13h) для доступа
к диску , и поэтому не может использовать диски более 8.4 ГБ , даже с новым (преобразующим
BIOS). (Разделы не могут быть более 2.1 ГБ , из за ограничений файловой системы
FAT16).

Windows 95 поддерживает расширенный INT13 интерфейс ,и использует специальные
типа разделов (c,e,f вместо b,6,5) чтобы обозначить что к партиции нужно обращаться
таким образом.При использовании этих типов разделов , begin и end поля содержат
"пустую" информацию , (1023/255/63). Windows 95 OSR2 поддерживает систему FAT32
(типы разделов b и c),которая позволяет использовать разделы почти 2 ТиБ размером.
насколько мне известнопо размеру файлов:
fat32 - макс 4 гб
fat16 - макс 2 гб
ext2 - макс 2 гб

А вот отсюда:
http://lafox.net/docs/Mandriva2005LE/Command-Line.html/ch09s01.html
Имеем:
Максимальный размер файла зависит от многих параметров (например, от размера
блока для ext2/ext3), а также возможно дальнейшее развитие, в зависимости версии
ядра и архитектуры. Согласно ограничениям файловой системы, текущий максимальный
объем в настоящее время составляет порядка 2 терабайт или более (ТБ, 1ТБ=1024
ГБ) для ext2 или ext3 на стандартных 32-битных машинах. Для JFS он может составлять
до 4 петабайт (ПБ, 1ПБ=1024 ТБ). К сожалению, эти значения ограничены также и
максимальным размером блочного устройства

Ответить   "Kanogin A.A." Mon, 1 Aug 2005 08:52:47 +0300 (#410860)

 

Народ! завязываем с максимальным размером файла! Там всё впорядке!!!
подскажите лучше как найти место порчи!

Ответить   Mon, 1 Aug 2005 14:39:32 +0400 (#411059)

 

Это именно ошибка передачи данных. Если бы я уперся в ограничения FS,
то была бы ошибка записи. Уменя там же лежат архивы большего размена и
всё в порядке.

Ответить   Mon, 1 Aug 2005 14:22:07 +0400 (#411052)