Поиск дубликатов файлов

← →
Dyakon_Frost © (2007-06-23 07:18) [0]

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

Заранее спасибо.

← →
Riply © (2007-06-23 08:47) [1]

> [0] Dyakon_Frost © (23.06.07 07:18)
>Честно говоря не знаю даже с чего начать.
С определения, какие файлы являются "дубликатами".

← →
Инс © (2007-06-23 10:19) [2]

Поиграем в телепатов :)

http://www.delphikingdom.com/asp/answer.asp?IDAnswer=26329
Пойдет?

← →
Anatoly Podgoretsky © (2007-06-23 12:13) [3]

> Dyakon_Frost (23.06.2007 07:18:00) [0]

Что такое дубликат, определение в студию.

← →
Dyakon_Frost © (2007-07-02 11:23) [4]

Разобрался спасибо!
Дублик - идентичные!

← →
Anatoly Podgoretsky © (2007-07-02 11:53) [5]

Очень грамотное определение.

← →
Игорь Шевченко © (2007-07-02 12:32) [6]

Я писал программу, сравнивающую размер и CRC16 файлов. Мне хватало.

← →
Anatoly Podgoretsky © (2007-07-02 13:09) [7]

> Игорь Шевченко (02.07.2007 12:32:06) [6]

CRC16 лишнее, потеря времени, достаточно явно сравнивать, после проверки на размер, лучше поблочно.

← →
Игорь Шевченко © (2007-07-02 13:29) [8]

Anatoly Podgoretsky © (02.07.07 13:09) [7]

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

← →
homm © (2007-07-02 13:50) [9]

> CRC16 лишнее, потеря времени, достаточно явно сравнивать,
> после проверки на размер, лучше поблочно.

Фигасе лишнее. Так имеем, нестрого говоря, «всего» n*m прочтений файлов, и n?n*m сравнений хешей, а без CRC16 тока n?n*m считываний файлов. Где n—количество файлов заданого размера, m—количество заличных размеров файлов.

← →
homm © (2007-07-02 13:51) [10]

Вместо знака ? длжен был быть юникодный знак умножения.

← →
Anatoly Podgoretsky © (2007-07-02 14:28) [11]

Лишнее, поскольку n*m прочтений файлов, затем расчет CRC, затем сравнение хешей, при этом n*m это полное чтение каждого файла, а при сравнение только до первого несравнившегося блока, что может ускорить на порядки. Да и операция расчета хеша значительно дольше чем простое сравнение.
Единственное оправдание может быть Игорь Шевченко © (02.07.07 13:29) [8] - где во главу угла ставится не скорость, а удобство для дальнейшей обработки.

← →
Игорь Шевченко © (2007-07-02 14:30) [12]

Anatoly Podgoretsky © (02.07.07 14:28) [11]

> где во главу угла ставится не скорость, а удобство для
> дальнейшей обработки

Да, конечно.

> Лишнее, поскольку n*m прочтений файлов, затем расчет CRC

Каждый файл собственно читается один раз - при вычислении CRC :)

← →
homm © (2007-07-02 14:40) [13]

> Да и операция расчета хеша значительно дольше чем простое сравнение.

Я бы сильно поспорил с этим утверждением. Операция вычисления хеша значительно быстрее, чем чтение с диска, а т.к. они идут паралельно, то от ее скорости ничего не зависит.

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

← →
Anatoly Podgoretsky © (2007-07-02 15:11) [14]

> Игорь Шевченко (02.07.2007 14:30:12) [12]

Не игнорируй замечание, что расчет CRC требует больше времени и главное, что при сравнение нет необходимости читать весь файл.

← →
Anatoly Podgoretsky © (2007-07-02 15:13) [15]

> homm (02.07.2007 14:40:13) [13]

> Операция вычисления хеша значительно быстрее, чем чтение с диска

Конечно, Hash := Random(X)

> другой для первого килобайта

Чем первый лучше второго, третьего и т.д.

> > другой для первого килобайта
> Чем первый лучше второго, третьего и т.д.

Э...

> [11] Anatoly Podgoretsky © (02.07.07 14:28)
> а при сравнение только до первого несравнившегося блока,
> что может ускорить на порядки.

Anatoly Podgoretsky © (02.07.07 15:11) [14]

> главное, что при сравнение нет необходимости читать весь
> файл

Этой мысли я не понял. Почему нет необходимости читать весь файл ?

> Этой мысли я не понял. Почему нет необходимости читать весь файл ?

Как это, если уже 5-я символ не совпадает, какой смысл сравнивать 6-й?

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

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

Anatoly Podgoretsky © (02.07.07 15:35) [19]

> Поскольку достаточно читать до первого не совпадающего байта,
> зачем читать дальше если уже известно, что файлы не равны,
> то есть не дубликат.

У меня на диске пара сотен тысяч файлов, это сколько ж мне чтений надо будет ? :)

Поиск дубликатов файлов Найти похожие ветки