Исходное сообщение
"Создание хешей файлов" Отправлено weldpua2008, 05-Янв-08 01:40
>[оверквотинг удален] > >Буквами X обозначены те блоки, которые включены в хеш.  Тогда те >блоки, которые обозначены буквой A можно произвольно менять, и хеш не >изменится. > >Так что этот метод не подходит не только для криптогафических применений, но >и для отслеживания изменений файлов.  Для глобальной идентификации файлов по >всему миру он тоже не подходит.  Тут лучше посмотрите в >строну хешей в сети edonkey.  Большой плюс -- они уже >посчитаны для миллионов файлов и подходят не только для "идентификации"... =) Во первых - Я максимум буду иметь 1-100млн файлов для которых хеш должен различатся. Во вторых Я хочу читать из файлов в 5-25-ти(n) местах одинаковое количество Кб. Допустим из файла размером 100Мб Я прочитаю 25*128Кб непрерывным потоком и отправлю на mdsum - который и посчитает хеш... Алгоритм такой - берём размер файла, делим на сколько блоков читать(n), читаем n блоков а размер блока(r) будет опредёлён так - если размер файла/n >1M читаем r=1М, всё остальное - r =размер файла/(2*n), если размер файла <N байт - читаем весь файл... >А вот если вы просто хотите создать некоторую маленькую строку, которой потом >будете идентифицировать файл локально -- например, при добавлении файла в фильмотеку >для него создаётся такой хеш, который служет идентификатором каким-то -- ваша >схема вполне подходит.  Только тут лучше не изобретать велосипед, и >использовать UUID, потому что для работы с ним уже много готовых >библиотек есть.  Да и сам UUID более стандартная вещь, чем >такой самопальный хеш. Да - локальное применение Не понял из манов по UUID -может ли она на основании фала выдавать данные... >Если вы таки хотите хеш по всему файлу, то учитывайте, что время его подсчёта будет как минимум равно времени чтения файла.  Поэтому замерьте cat file > /dev/null для начала.  Это и будет минимально достижимое время *в принципе*. нет. Про cat - понял, тут наверное и запираются md5sum &etc