Как програмными средствами сравнить примерно 50 тисяч файлов на идентичность, при этом размер файла может достигать размеров до 2 ГБ. 

каким образом сравнить???
по размеру или есть другие параметры????

---------------------

А мо есть конкретное задание - типа найти пару одинаковых???????

Это сообщение отредактировал(а) Azzdorf - 21.11.2007, 19:00

tarasD, если возможно два варианта идентичны и неидентичны, то считайте с файлов хеш суммы (CRC или MD5) и сравнивайте их - если будут равны, то файлы идентичны.

marcusmae, ну для 50 тыс. файлов делать md5 - это жестоко (особенно если учесть возможный размер файлов). Но похоже это единственный приемлемый метод в данной ситуации (ускоряет сравнение в десятки раз). Просто стоит сначала проверять размеры сравниваемых файлов, так как 10кб тхт файл не может быть идентичен 4Гб iso-образу 

PS никто не знает, есть ли в .Net средства для получения СRC или MD5? Изначально благодарен за ответ.

MD5 - System.Security.Cryptography.MD5, CRC вроде нет. В любом случае, я бы ручками их сделал, т.к. у меня большие сомнения в производительности стандартной реализации.

tarasD было бы проще если бы точнее описал задание - тут бы и исходничек родился, но Domovikпоходу прав, если большой разброс по размеру файлов - я бы разбил файлы на несколько груп по размеру, что-бы оптимизировать в плане скорости

например там файлы до 1000кб
1000кб-10мб
10мб-100мб
выше 100мб

а потом прогнать if-оператором при помощи сравнения with use MD5

думаю так будет быстрее хотя можна и поспорить

Я написал через md5. Программа считает 40 минут 60 тисяч файлов, а надо за 5 минут. Причем я учитивал такой вариант когда два файла за размером не равни, то соответственно  файли не равни.  

попробуй вариант с группами - мож реально поможет(притом что МД5 долго)
может есть смысл до 10 или 100 метров сравнивать по МД5 а после по размеру - должно ускорить (попробуй звять для сравнения только файлы до 10 метров и посмотреть сколько выйдет их сравнение через МД5)

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

Узкие места :

1) КОД
Если под .NET пишите, то неудивительно, что медленно. Возьмите какую-нибудь из программок, проверяющих контрольные суммы (коих бесчисленное множество, например, эта) и сравните их скорость со своей программой на каком-нибудь одном файле. Прирост скорости могла бы дать реализация под native С. Если всё грамотно сделать, то ускорение в 8 раз в принципе достижимо 

2) ДИСК
Магнитные диски работают медленно и, чтобы добиться большего, нужно упорядочивать файлы. Ко множеству мелких файлов долго обращаться по файловой системе. Можно объединить в более крупные архивы (или "непрерывные" файлы другого вида) - возможно, будет жеваться быстрее. Этим или другим образом желательно добиться того, чтобы данные, которые Вы анализируете были бы как можно меньше фрагментированы по диску.


Это сообщение отредактировал(а) marcusmae - 22.11.2007, 21:31

может сделать как на многих крупных серверах - создать файл-регистр, к котором хранить даные о файле (расположение, размер...) и в т.ч. МД5 - у по надобности пробигать и сравнивать???

или общая задача другая????

Да, этот вариант мне тоже по душе.

1) За первый прогон создать "индексный" файл с инфой "файл & размер". 
2) Потом пройтись по файлу и найти группы файлов с одинаковым размером (групп будет не много, потому что почти нереально, чтобы разные файлы содержали одинаковое количество байт).
3) Каждую группу проверить MD5.

Хм, не годится : файлы можно будет подменить. По размеру Вы не определите, произошло ли это.

Это может произойти в любой момент сравнения. Какой бы алгоритм ты ни избрал   

P.S. marcusmae, по контексту понятно, что ты подразумеваешь что-то особенное под "подменить". Только вот я не пробью что  
Давай на ты

Добавлено через 42 секунды

Кста, "файл" спокойно поместится в оперативке

как вариант, если есть сервер с базой данных, занести туда записи для всех контролируемых файлов. При первом прогоне - проверить все фалы на идентичность, поставить отметку в полях "synchronized" & "equal". Далее, на кадой машине, где лежат проверяемые файлы крутицца сервис виндовз, который в рантайме отслеживает изменение файлов с помощью FileSystemWatcher и сбрасывает в базе у записи, соответстующей измененному файлу признак "synchronized". При проведении очередной проверки, проверяем только те записи, у которых сброшен "synchronized" и после проверки опять же его поднимаем...

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

Это сообщение отредактировал(а) 1stain - 23.11.2007, 12:10

Ну можно, действительно, нехитрым сишным кодом подвинуть дату модификации файлов лет эдак на десять в прошлое или в будущее  Только зачем? Просто, скажем, какой-нибудь фоновый процесс взял и обновил один из файлов - вот и всё, кэшированные суммы уже не действительны...



Так, и что? = Алгоритм подмену заметит, а твой индексер просто выдаст значение из базы и будет неправ.  Или, как предлагает 1stain, кеширование должно работать в связке с системными сервисами по доступу к файловой системе. Типа, уже почти Windows Vista