>[оверквотинг удален]
>
>Буквами 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