Не, я имел в виду примерно как в md5deep. Ставлю сканировать директорию

C:\ToBurn\DISK61

потом записываю результат, скажем в C:\ToBurn

А потом сверяю с диском W:\

И вот в момент сверки проходит некая эвристика, отрезается лишняя часть пути C:|... заменяется на W: и т.п.

Ибо в md5 файле хранится полный путь, начиная с диска.

Только что посмотрел. Файл .md5, созданный md5deep, действительно может хранить полный путь к файлу. Честно говоря, не знал, потому что попадались только .md5 вообще без путей (и это правильно).

Проблема в том, что я видел кучу разных вариантов .md5. Например:

хэш имя_файла
хэш *имя_файла
имя_файла хэш
MD5 (имя_файла) = хэш

В общем, кто во что горазд. И, честно говоря, поддерживать _все_ эти варианты у меня нет ни малейшего желания. Тем более, что hasher хоть и умеет проверять .sfv и некоторые .md5, но создавать будет только чек-файлы в своем собственном формате .afv

Вот детали этого формата и можно обсудить.

P.S. Кстати, вот хранить _абсолютные_ пути в чек-файле я считаю идеологической ошибкой :) А насчет относительных путей - надо подумать.

Ну почему md5deep хранит абсолютные пути - фиг знает. Без относительных обойтись нельзя. У меня файлы с одинаковым именем тысячу раз могут встречаться на диске...

Кстати, из него же. Для оптимизации (видимо) он умеет в первую позицию "псевдо-md5" файла сохранять размер. Размер не сошёлся - хэш даже запускать не надо. И так всё ясно.

Сохранение размера файлов и поддержка относительных путей - точно будут.