Идея: утилитка для восстановления битых файлов!

Oleg_SK

> В аттаче программка.



Эта работает.

 

На модеме превышение скорости происходит из-за того, что информация сжимается.

Высокая скорость в основном при загрузке страниц, или exe, где некоторые части хорошо сжимаются.

Ну а архивы быстрее никогда не будут грузиться.



У меня модем Genius, софтовый, самый дешевый. Благодаря новой телефонной линии соединение происходит на скорости 52000кбит.

Страницы текста грузит 8-12кбайт/с.

 

Я нашел время для того, чтобы сделать новую версию своей утилиты (причем, в этом деле мне активно помогали многие участники этого форума, может быть даже не подозревая об этом). Выкладываю ее для бета-тестирования. В этой версии я воплотил все возможности, которые задумал с самого начала и кое-что сверх того. Кроме того IMHO она гораздо производительней и надежнее своей предшественницы. А также в ней устранен ряд ограничений присущих первой версии. Пожалуй на этом можно было бы и закончить этот проект, но, как обычно это бывает, в процессе разработки программы мне в голову пришло еще пара идей (о них я расскажу, когда буду говорить о том, что я подумываю реализовать в следующей версии этой утилитки).

Итак, теперь я вкратце расскажу о том, что изменилось, и какие возможности добавились в этой версии. В общем, можно сказать что это совершенно другая программа. От первой версии осталось только основное диалоговое окно (со своей оконной процедурой), которое, кстати, тоже претерпело значительные изменения. Вся функциональная часть программы переписана с нуля. При ее написании я произвел некоторую оптимизацию использования ею памяти и ее работы с диском. Это позволило значительно повысить ее производительность. Также хотелось бы обратить ваше внимание на то, что эта версия утилиты (IMHO) больше не в чем не уступает своему основному конкуренту (т.е. утилите Zidrav v 3.5) при работе с одиночным файлом. Более того, по многим параметрам она лучше Zidrav. Позже я приведу для сравнения результаты их тестирования. Далее я кратко отмечу основные изменения и дополнения появившиеся в новой версии:

1) Теперь утилитка стала многопоточной. В ней есть интерфейсный поток и создающийся по мере необходимости служебный поток, который предназначен для выполнения функциональной части утилиты. Таким образом при выполнении длительных операций с большими файлами ее интерфейс больше не замораживается. Теперь в этом плане моя тулза не чуть не хуже Zidrav’а;

2) При выполнении потенциально длительных операций утилита выводит т.н. Wait-диалог содержащий информацию позволяющую судить об объеме проделанной работы. Из этого диалога можно прервать выполнение длительной операции не дожидаясь ее завершения. Также из этого окна можно перевести работу утилиты в фоновый режим. Из этого режима утилита выйдет сама в конце выполнения поставленной перед ней задачи или же юзер сам может вывести ее в нормальный режим в процессе выполнения утилитой поставленной задачи. Фоновый режим отличается от рабочего режима тем, что при переходе в него утилита скрывается с панели задач и выводит свой значок в трее. Также при переходе в фоновый режим рабочему потоку назначается фоновый приоритет (THREAD_PRIORITY_IDLE). Таким образом в фоновом режиме моя утилитка будет меньше мешать вам работать с другими программами;

3) В режиме сканирования битого файла у вас появилась возможность самостоятельно задать размер контрольного блока. Кроме того теперь утилита может вычислять для контрольного блока не одно контрольное значение, как это было в первой версии (там использовался метод XOR), и до сих пор есть в Zidrav’е. Моя утилитка позволяет выбрать любую комбинацию из трех возможных методов расчета контрольных значений (MD5, CRC32 и XOR). Указание сразу нескольких вариантов контрольных значений повышает надежность работы программы, но также, к сожалению, увеличивает размер контрольного файла и уменьшает производительность утилиты. Но, как говорится, за все надо платить, в том числе и за надежность. Обратите внимание, что никто не заставляет владельца битого файла выбирать больше одного контрольного значения. Более того, я думаю что владелец валидного файла не обрадуется скачав не обосновано большой контрольный файл, а у него есть возможность узнать помимо прочего, какие именно контрольные значения задействованы и используемый размер контрольного блока (для этого в режим сканирования валидного файла добавлена информационная поддержка). По умолчанию используется метод CRC32, а размер контрольного блока: 1000H.Таким образом, в этом плане моя утилита значительно превосходит Zidrav;

4) Я добавил еще один режим работы утилиты: Предварительная проверка файла. В отличие от других режимов работы он является второстепенным и поэтому переключение в него реализовано по другому (для этого есть спец. кнопка находящаяся в правом верхнем углу клиентской области основного диалогового окна). Благодаря этому режиму можно проверить валидность файла с меньшими затратами на сетевой трафик, чем в основных режимах (раньше для этого было нужно пересылать контрольный файл). В общем, этот режим представляет собой нечто вроде встроенной тулзы типа HashCalc (правда, в облегченном виде, т.к. предоставляет выбор только из трех возможных контрольных значений). В общем здесь все интуитивно понятно: просите чтобы владелец валидного файла рассчитал контрольные значения для своего файла и выслал их вам, потом делаете тоже самое для своего предположительно битого файла и сравниваете полученные значения с теми которые вам прислали, после чего делаете вывод: валиден ваш файл или нет. IMHO, наличие этого режима – это еще один аргумент в пользу моей утилиты. В Zidrav’е ничего похожего нет;

5) В конце выполнения поставленной задачи в сканирующих режимах на экран теперь выдается информационное окно, сообщающее некоторые подробности о проделанной работе. Это IMHO еще один аргумент в пользу моей утилиты;

6) Теперь моя утилита производит контроль валидности своих служебных файлов (контрольных и ремонтных), причем позволяя использовать для этого любую комбинацию из трех возможных методов расчета контрольных значений (MD5, CRC32 и XOR). Этот контроль можно отключить. По умолчанию контроль включен, и используется метод MD5. IMHO, в этом плане у моей тулзы тоже больше возможностей, чем у Zidrav’а;



Ладно, пора закругляться, но это еще не все. Пойду высплюсь, а потом продолжу…



2043359910__FileDoctor v2.0 (beta).exe

 

Замечательная программка - первый раз про нее сегодня прочитал.



Вопросы (возможно это уже все есть в твоей реализации, поэтому заранее извиняюсь):

1. Как насчет восстановления файлов с вставкой/удалением символов (то есть таких, у которых вторая часть смещена относительно базовых позиций в оригинальном файле) ?

2. Как насчет двоичного поиска битой области в случае, если возможен on-line контакт между двумя копиями ?

3. Зачем использовать такие медленные хеш-суммы как MD5 и прочие с ней ? Использование обычных (не криптографических) ускорило бы процесс подсчета примерно в 10-20 раз и объем файлов с ними раза в три.

4. Ты знаком с протоколом синхронизации файлов RSync, которому уже года три или четыре, и который портирован под все современные ОС ? Может у него кое-что возьмешь интересное ?

 

OLS

Мне приятно что ты не остался равнодушен к моей работе и даже предложил пару своих идей. Теперь отвечу на твои вопросы:



1. Этого пока нет. Возможно в будущих версиях я это реализую;

2. Это пока не реализовано. Более того, я об этом даже не думал. У меня сейчас абсолютно нет опыта сетевого программирования, поэтому я даже не представляю как это можно сделать. Но вообще-то это интересная идея, и возможно в будущем (отдаленном) я добавлю эту функциональность в тулзу;

3. Я предоставил возможность использования этих методов для вящей надежности результата. На самом деле никто не заставляет тебя использовать “тяжелые” алгоритмы. Если тебе нужна скорость, то можешь использовать только один какой-нибудь метод. Что касается скорости работы утилиты, то здесь “бутылочным горлышком” является скорость работы дисковой подсистемы компа. Я сомневаюсь что можно повысить скорость работы утилиты 10-20 раз. Чтобы не быть голословным я произвел (с помощью секундомера) замер времени работы утилиты в режиме сканирование битого файла. Для обработки я скормил тулзе файл размером 650Mb. Перед началом работы я отключил контроль валидности служебных файлов и установил размер контрольного блока равным 1000H (это значение по умолчанию). Вот какие результаты я получил:



MD5 CRC32 XOR

0 0 X - ~21 сек.

0 X 0 - ~20 сек.

0 X X - ~20 сек.

X 0 0 - ~21 сек.

X 0 X - ~20 сек.

X X 0 - ~34 сек.

X X X - ~34 сек.



В общем я не могу сказать что полученные результаты меня не удивили, но мое мнение насчет того, что является “бутылочным горлышком” они подтверждают.



4. Теперь знаком Я так понимаю, что применив его можно реализовать то, о чем ты говорил в первом вопросе. Я нашел описание этого алгоритма на сайте www.sitforum.ru Описание довольно понятное, но все же для меня в нем осталось несколько темных мест. Хотелось бы посмотреть реализацию этого алгоритма на каком ни будь языке программирования.

 

На самом деле программа вытекла из незнания существующих программ - именно такой алгоритм используют Edonkey, Kaaza, Shareaza и прочая и прочая.

У каждого из сетки есть файл. У файла - хеш, клиент ищет _многих_ людей с этим файлом. И по кусочку у каждого выкачивает.

 

rst

Да, так оно и было. Я этого и не скрывал. А развивать я ее продолжаю потому, что это всетаки не самая плохая практика. К томуже это лучше, чем тренероваться на безполезных программах-полигонах (чем я раньше и занимался).



З.Ы.: Нашел я одну из указаных тобой программ: Shareaza_2.1.0.0.exe Ее размер 3227Kb, думаю что и у других тоже не маленький... FileDoctor же весит ~46.5Kb

 

rst

Нечто отдаленно похожее я задумал реализовать в следующей версии своей тулзы.

 

rst

RSync в отличие от файлообменных сетей может обновлять слегка измененный файл (хотя находить его самостоятельно естественно не может - хеш-суммы разные)



у нас по ночам все FTP-сервера по RSync-у обновлениями обмениваются - очень эффективный протокол получается относительно объемов трафика



Oleg_SK

да, интересно - я думал узкое горлышко не в дисковых операциях

 

rst

Я никогда не пользовался услугами пиринговых сетей, поэтому мало знаю о их возможностях. Недавно нашел в сети несколько вводных статей по этой теме. После их прочтения, я понял, что чего-то не вкурил... А именно, я не понимаю, почему вы считаете, что утилиты подобные моей ненужны? Да, действительно, если в процессе скачивания файла из пиринговой сети произойдет повреждение передаваемого блока, то программа-клиент отремонтирует его. Тут все верно. Проблема в том, что если вы скачали файл не из этой сети и он окажется битым, то, IMHO, пиринговая сеть ничем вам помоч не сможет, в отличие от моей тулзы... Или я чего-то не понял?



З.Ы.: Возможна задержка с ответом.

 

Заранее извиняюсь за поднятие столь древней темы. Хотелось узнать какова судьба проекта? EXE я видел. Жалко пакетного нет режима или хотя бы приема параметров из командной строки. Может кто-нибудь поделится исходниками. Я бы попробовал сам доработать.

 

проблема и ЕХЕ остались в 2оо4-2оо5х годах, теперь есть торренты .)

 

Oleg_SK

можещь еще поиграться с моей консольной утилиткой CRC32.EXE, она аналогична quickPAR или ICEECC, но работает с 32-разрядными кодами Рида-Соломона, а не с 16-битными, как первые две, плюс можно выбрать матричный квадратичный код (и квадратичный по памяти) ключем -tm3 (хорош для небольшого числа блоков) либо логарифмический (и линейный по памяти) через FFT (хорош для десятков тысяч и сотен тычяч блоков, по умолчанию).

Коды Рида-Соломона не так эффективны для поставленной тобой задачи, так как требуют не просто нарезки, но и кодирования/декодирования. Зато полученная заплатка-лечебный блок чудесным образом может залатать ЛЮБУЮ дыру, а не только одну конкретную. Для твоей задачи когда есть целый файл это может показаться излишеством, но для задачи получения писем из прошлого себе любимому, когда оригинала нет, самое оно.

Ссылку дать не рискну, тут в проектах ветка была.

Ключи примерно такие
1) Алиса-Анна производит 5% избытка с хорошого фала(файлов) путем разбиения на 10000 блоков.
crc32 -wt -r
crc32 -wrr10000-5% -pow10
2) Алиса-Анна посылает заголовочные файлы crc32.tab и crc32.sum Бобу-Борису
3) Боб-Борис исполняет crc32 -crr
и обнаруживает например 443 блока потерянных данных
4) Б-Б пишет письмо А-А - пришли мне 443 блока
5) А-А присылает Б-Б файлы (можно зарарить без сжатия в один файл, распаковывать обратно не нужно)
s00_vol000001.bin
s02_vol000002.bin
s04_vol000010.bin
s05_vol000010.bin
s06_vol000020.bin
s08_vol000100.bin
s09_vol000100.bin
s10_vol000200.bin
6) Б-Б делает дирку скажем 123 и сует туда блоки
и исполняет
crc32 -rrr -sa123
и получает целый файл(ы) в дирке CRC32_Repaired
7) Если обнаруживается, что убито больше 5%, скажем конкретно 663 блока, то А-А пересчитывает избыточность командой
crc32 -wrr10000-663 -pow10
8) Дальнейшие шаги понятны

Этот трахаторий имеет свои недостатки но равно как и достоинства перед посылкой некодированных блоков:
1) Нечувствителен к сдвигу, ему все равно, изменены байты или вообще выпали из потока(набились мусором), то бишь лечит сдиги инфы
2) Требует также три посылки, как и прямой метод с некодированными блоками, но бинарники отсылает только А-А,
а Б-Б отсылает только один раз текстовое сообщение в виде числа сколько ему нужно блоков.

Ну примерно так =)))

 

Блин, тема 2004 года! =)))

 

Мне программа нужна для контроля целостности файлов. Восстановить я их всегда и сам смогу, но нужно знать какой именно блок битый. В данный момент правлю par. Прога подходящая хоть и с избыточным функционалом. Мне ведь надо только посчитать контрольные суммы для каждого блока отдельно, а информация для восстановления не нужна. Правлю потому что par не показывает какой из блоков битый. Просто пишет что есть 120 блоков из 125 к примеру. Quickpar вообще сказка, но имеет тот же недостаток, а исходников нет.

 

А зачем ему писать, какие именно 5 блоков из 125 вылетели, если ЛЮБЫЕ из 5 блоков коррекции могут залатать ЛЮБЫЕ 5 дыр? Сказка то он сказка, но тока работает в 100 раз медленнее моей проги, так как умножает в столбик, а моя типа Штрассена через Быстрое Преобразование Фурье =)))

 

mr_slonyara
Нужна прога которая разбивает файлы на блоки и выводит номера отличающихся? По-моему такое можно написать за 10 минут.

 

А вот утилита восстановления, которой многие пользуются и которая зарекомендовала себя с хорошей стороны: rdko

 

Как я и писал мне не нужны информация для восстаноовления. Только файл с контрольными суммами. rdko мне похоже подходит.

 

Что значит не нужна инфа для восстановления? Тебе нужна будет потом инфа восстановления в виде рипнутых блоков, которые тебе потом пришлют. Ну хорошо, ты узнал, что у тебя битых не просто три блока, как в случае QuickPAR или моей прожки, а скажем именно битые блоки 5,7,11. Значит ктото должен будет тебе потом рипнуть эти блоки с номерами 5,7,11 и прислать. Это и будет инфа восстановления в твоем случае, но тока она не будет обладать совершенно никакой универсальностью, она сможет вылечить только блоки 5,7,11 но не сможет вылечить три других каких-нить блока.

RDKO лечит ли искажения со сдвигом, если размеры файлов отличаются? Скажем, если стереть первый байт и перезапомнить файл, чтобы вся инфа сдвинулась? Спрашиваю без подтекста, просто пока лень самому спытать