[Iska]

НО какова вероятность изменения файла с сохранением изначального размера? »

NikolayHAOS, Вы неправильно ставите вопрос.

читать дальше »

Любая ненулевая вероятность совпадения ставит жирный крест на использовании такого метода. Даже в случае MD5 она не нулевая (хоть и весьма, весьма низкая), а уж при попытках основывать отбор посредством сравнения по размерам… Даже не пытайтесь делать отсев файлов по такому слабому критерию — чревато печальными последствиями.

[NikolayHAOS]

Iska, Абсолютно согласен с вами.
Как правильно запустить скрипт, подскажите пожалуйста. Бьюсь бьюсь весь инет перерыл, ан нет все равно ошибка, мобыть в скрипте чего не так?

[Kazun]

Выше я написал и тов. Iska дал ссылку, что требуется версия PowerShell 3.0 и выше.

Посмотреть версию PowerShell - $PSVersionTable.PSVersion

[NikolayHAOS]

Kazun, Агромное спасибо вы просто гений, все заработало.
Iska, Почему то считал что Framework 3.0 включен в 4.5.1 - ошибся. Установил и все отлично.

чревато печальными последствиями. »

И не говорите, подредактировал файл, поставил знак вопроса заместо точки, размер тот же, а вот хеш нет :-)
Всем агромное спасибо.
З.Ы. Жаль, что сам нефига не понимаю в этом скрипте, ща попробую изменить пути на свои. И отпишу.

Все работает. Благодарю.

[Гуллипут]

NikolayHAOS, я говорил про кодировку самого bat-файла. Кодировка сравниваемых файлов безразлична. Они могут быть даже двоичные, только надо добавить после команды fc ключ /b:

Код:

for %%f in (d:\2\*.*) do (
  fc /b "%%f" "d:\1\%%~nxf"|find "FC: различия не найдены"
  if not errorlevel 1 del "%%f"
)

Iska, по крайней мере, это решение значительно компактнее, чем то, что предложил Kazun.
Поскольку bat - это язык файло-ориентированный, многие операции над файлами в нём программируются намного проще, чем в других. Поэтому я не считаю это садомазохизмом.

[Iska]

Гуллипут, дело, разумеется, не в Вашем коде, а в особенностях сравнения «fc.exe»: в общем случае сравнение по хэшам выигрывает в производительности.

[NikolayHAOS]

Гуллипут, Спасибо и ваш метод отлично работает, И в мне легче разобраться в вашем коде, так как его почти там нет :-).

[Гуллипут]

Гуллипут, дело, разумеется, не в Вашем коде, а в особенностях сравнения «fc.exe»: в общем случае сравнение по хэшам выигрывает в производительности. »

Сомневаюсь. Ведь для вычисления хэша надо всё равно прочитать весь файл. Выигрыш только за счёт операций сравнения, зато вычисление хэша занимает больше времени, чем просто чтение строк из файла. Хэш полезен в случае, когда он вычисляется каждый раз при изменении хэшируемого объекта, с тем, чтобы в дальнейшем при сравнении уже сравнивать только хэши. То есть затраты времени "распределяются" более равномерно.
Правда, я не разбирался в алгоритме, который выложил Kazun, может, он так и делает ? Но для этого ему надо ставить обработчик на событие изменения файлов в каталоге. В принципе, реально, я это делал на Delphi, но не знаю, может ли это PowerShell. В нём я не разбираюсь: пару лет назад проглядел одну книжку, но на работе это не используется, поэтому и благополучно забыл прочитанное.

[Iska]

Сомневаюсь. Ведь для вычисления хэша надо всё равно прочитать весь файл. »

Гуллипут, для сравнения — тоже. И, в отличие от сравнения по хэшам, читать, в случае сравнения MxN файлов, каждый из M придётся в худшем случае ровно N раз (вместо одного раза). И так же читать M раз каждый из N файлов. Вот почему «fc.exe» хуже подходит сравнения по хэшам. Можно предварительно сравнивать по размерам, это, в общем случае, даст заметную экономию. Но именно в некоем «общем случае», а сравнение ведь, как правило, проводится отнюдь не для неких усреднённых «общих случаев», а конкретно там, где заранее предполагается наличие какого-то числа одинаковых файлов.

CloneSpy умеет работать с предварительно рассчитанными им и сохранёнными наборами хэшей файлов. Это удобно в случае, аналогичном рассматриваемому — когда неизменный или редко обновляемый набор файлов сравнивается со вновь поступающими наборами файлов.

[Гуллипут]

Iska, я сравниваю не каждый файл с каждым, а файлы с совпадающими именами. Поскольку "одинаковость файлов" я понял, как совпадение не только содержимого, но и имён.