Контроль изменения файлов

[Johnson]

Здравствуйте, уважаемые.

Есть сторонняя программа, состоящая из большого количества файлов, причем файлы по большей части имеют приличный размер (суммарно порядка 15Гб).

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

Столкнулся с проблемой сравнения файлов.
Если высчитывать MD5 содержимого файла - получается оочень долго, в 4 потоках составляет лист около 5 минут.
Про CRC32 читал, что контрольные суммы одного и того же файла могут различаться на разных файловых системах при разном локальном времени компьютера.

Подскажите, какой лучше взять алгоритм, чтобы безошибочно определить изменение хотя бы одного байта, но при этом который будет работать относительно быстро?

[Serge_Bliznykov]

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

Извините, но это бред. (точнее, может и есть кривые реализации, в которых такое происходит, но я подобной фигни не встречал. Время для расчёта CRC32 вообще никоим боком не используется!

Подскажите, какой лучше взять алгоритм, чтобы безошибочно определить изменение хотя бы одного байта, но при этом который будет работать относительно быстро?

никакой. Вам нужно будет прочитать 15 Гб при любом самом наибыстрейшем алгоритме!

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

[Johnson]

Спасибо, Сергей.
Попробую положиться на CRC32, всё же это быстрее мд5.

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

И ещё вопрос. Из WinAPI нет ни чего подобного для вычисления некоей контрольной суммы?

[Аватар]

CheckSumMappedFile

[Serge_Bliznykov]

Попробую положиться на CRC32, всё же это быстрее мд5.

недостаток CRC32 - возможность коллизий (это когда разное содержимое даёт одинаковую контрольную сумму). Для CRC32 она относительна высока.
НО!
CRC32 + имя_файла + его_размер - дадут вам практическую гарантию/защиту от подобных коллизий!

В файлах нет заголовков или другой отличительной информации, более того, они зашифрованы.

ну. так вам и карты в руки.
Вы знаете антивирус Касперского?
там, например, есть XML файлы в составе баз сигнатур.
в конце там присутствует такой текст:

;:10KD0O+dP2EcVMDWotQCbxPRqVC60+Jkpw+j8JPobLhaaXLDqWAkekswTURTkKXQypw2mOg3R8QYHg0g6+bb/RkM%%

это 100% какая-то контрольная сумма/ЭЦП для данного файла.
Чтобы ни один байт в файле не был изменён без ведома Хозяина.

Это я к чему рассказываю.. Добавьте в конце каждого своего файла контрольную сумму. (если файл зашифрован - то наличие контрольной суммы - это ещё одна проверка целостности файла). Считывайте эту сумму из файла и сверяйте с той, что на сервере. Скорость будет более чем достаточной !

[Johnson]

Файлы не мои, как я уже писал.
И дописывать к ним ни чего нельзя.
Спасибо за советы, вечером буду пробовать.

[Serge_Bliznykov]

Файлы не мои, как я уже писал.
И дописывать к ним ни чего нельзя.

"мопед не мой, я только разместил объяву" :-D

ещё один вариант решения (просто придуманный трюк для ускорения)
создаём в нужном (или любом доступном рабочем каталоге, например %AppData%) каталоге файлик (формат тоже не важен. я бы использовал какую-нибудь простенькую БД, но и обычный XML подойдёт). Такой файлик (если есть доступ, конечно) может быть размещен и на сервере.
в данном файле следующая информация:

имя файла; дата_время послед_модификации; CRC32 от малюсенькой части файла (например, первых 4-х кб + последние 4 кб; MD5 _полного_ файла

перебираем все файлы на сервере.
для каждого файла в цикле находим соответствующий ему файл в локальной папке.
Если нашли, то по имени находим Конт.Данные (КД) и сравниваем с фактическими (которые имеются у реального файла). Разумеется, полную MD5 на этом этапе не проверяем!
Если размер+дата_модификации+CRC32_heade r_footer из БД совпали с фактическими - то этот файл считаем актуальным, дальнейшую обработку его не производим. Если любой из параметров отличается - идём на контроль ПОЛНОЙ MD5: считываем MD5 с сервера, считаем локальную MD5 - если MD5 не совпадают - скачиваем новую версию файла.
В любом случае после обновляем КД в нашей локальной БД.

Очевидно, если для какого-то файла нет данных в нашей локальной БД (или БД вообще пустая), то выполняем полный расчёт MD5 и сохранение всех КД в нашей локальной БД.

Разумеется, при первом запуске программа будет "пыхтеть" достаточно долго (минут 5, согласно вашему утверждению). Зато потом контроль можно осуществлять за секунды...

Примерно так...

p.s. а ещё, в NTFS есть такая фишка, как дополнительные файловые потоки. Тот же Касперский ими пользуется. Можно сохранять контрольную сумму файла в доп.поток.