Показать полную графическую версию : [решено] Автозамена при перемещении
с чем может быть связана невероятно низкая скорость работы скрипта? »
очевидно, из-за использования FC.EXE - при наличии одинаковых файлов проводится бинарное (байт за байтом) сравнение содержимого на предмет совпадения - это надёжней, чем сравнение размера, но и существенно медленней, варианты ускорения:
- ограничиться для сравнения размером, но могут встретиться два разных файла одного размера;
- использовать более быстрые альтернативы, чем FC.EXE... например, порт Unix-утилиты DIFF.EXE
а если использовать diff.exe, то кинуть его в папку к скрипту, а скрипт будет выглядеть так?:
@echo off
SETLOCAL EnableDelayedExpansion
Call :MainExe Material3
EXIT
:MainExe %folder_name%
::---------------------
set "set $d="& if "%~1"=="" GoTo:EOF
for /f "delims=" %%d in ('dir/b/s/ad "%~1.*"') do if "%%~xd"=="" (
for /f "delims=" %%f in ('dir/b/s/a-d "%%d"') do (
set "$d=%%~dpf"& set "$d=!$d:%%~dpd=%%~dpd..\..\!"
call:MoveRen "%%f" "!$d!"
))
GoTo:EOF
:MoveRen %source_file% %destin_folder%
::-------------------------------------
set "$s="& set "$n="& if "%~1"=="" GoTo:EOF
if not exist "%~2" md "%~2"||exit/b 1
:MoveRen_Loop
if not exist "%~2%~n1%$s%%~x1" move "%~1" "%~2%~n1%$s%%~x1"& GoTo:EOF
diff/b "%~1" "%~2%~n1%$s%%~x1">nul&&(del/f/q "%~1"& GoTo:EOF)
set/a "$n+=1"& set "$s=0!$n!"& set "$s=_!$s:~-2!"
GoTo:MoveRen_Loop
конечно нет, у DIFF совсем другие ключи, заменяемая строка будет выглядеть так:
diff -q --binary "%~1" "%~2%~n1%$s%%~x1">nul&& (del/f/q "%~1"&& GoTo:EOF||exit/b 3)
а скажите, как тогда изменится весь скрипт?
так?:
@echo off
SETLOCAL EnableDelayedExpansion
Call :MainExe Material3
EXIT
:MainExe %folder_name%
::---------------------
set "set $d="& if "%~1"=="" GoTo:EOF
for /f "delims=" %%d in ('dir/b/s/ad "%~1.*"') do if "%%~xd"=="" (
for /f "delims=" %%f in ('dir/b/s/a-d "%%d"') do (
set "$d=%%~dpf"& set "$d=!$d:%%~dpd=%%~dpd..\..\!"
call:MoveRen "%%f" "!$d!"
))
GoTo:EOF
:MoveRen %source_file% %destin_folder%
::-------------------------------------
set "$s="& set "$n="& if "%~1"=="" GoTo:EOF
if not exist "%~2" md "%~2"||exit/b 1
:MoveRen_Loop
if not exist "%~2%~n1%$s%%~x1" move "%~1" "%~2%~n1%$s%%~x1"& GoTo:EOF
diff -q --binary "%~1" "%~2%~n1%$s%%~x1">nul&& (del/f/q "%~1"&& GoTo:EOF||exit/b 3)
set/a "$n+=1"& set "$s=0!$n!"& set "$s=_!$s:~-2!"
GoTo:MoveRen_Loop
Tosyk, не хочу замусоривать ветку копиями одного и того же кода (и вам не советую)
подсветил заменяемую строку в посте #16 (http://forum.oszone.net/post-1591204-16.html)
прошу меня простить, если нужно я почищу ветку
начинаю тестировать, натравил скрипт
к сожалению скорости особо не прибавилось, после 600-700 элементов начинаются серьёзные задержки - 40-90 сек для каждого файла, и это только файлы размером в 1 кб, однако впереди файлы размером от 1 до 24 мегабайт (56000 элементов),
на самом деле я за надёжность!, но скажите как будет выглядеть скрипт не сравнивающий файлы по-байтно.
p.s.: и скрипт опять остановился на 814-ом файле :)
к сожалению скорости особо не прибавилось »у этих утилит разный алгоритм: если FC для выдачи результата должен просканировать файл от начала до конца, то DIFF'у с опцией -Q достаточно дойти до первого отличающегося байта, чтобы выдать отрицательный результат сверки... Если замена не помогла, значит не поможет и "размер файла"... значит, проблема в другом - например, в большом количестве файлов и задержками интерпретатора, или "сдерживанием" скрипта со стороны ОС (тот же антивирус, который полностью отключить невозможно)
скрипт опять остановился на 814-ом файле »это какой-то постоянный файл?.. может у него какое-то особенное имя?.. про лог уже писал выше
если скрипт применяется к каждому файлу отдельно, то скорее всего дело в задержке его какими-то условиями стороны ОС »
тот же антивирус, который полностью отключить невозможно »
а как это проверить? ни в службах ни в программах отключенного касперсого нет
это какой-то постоянный файл? »
нет, каждый раз разный, да и мне кажется дело не в имени, никаких специфических символов не используется, только буквы и цифры
Если замена не помогла, значит не поможет и "размер файла" »
я даже не знаю, что поможет, возможно всё таки попробуем этот скрипт, который сверяет размер?
файлов действительно очень много
amel27, приветствую, поможете мне?
Tosyk, увы, мне отсюда не видно,
пост #18 (http://forum.oszone.net/post-1591219-18.html) - как получить лог для проблемного запуска (и не забыть убрать @echo off)
Хорошо, сейчас сделаю распаковку, а затем с логом запущу скрипт.
Я всего лишь хотел попросить помочь со скриптом проверяющим только размер. возможно получилось бы, потому что распаковка занимает часа 4, плюс скрипт "по теме" до проблемного места (814 файл) работает около 2 часов
Tosyk, простая замена одной проверки другой ничего не даст - даже чуть замедлит работу, тут нужно пересматривать весь алгоритм... попробую глянуть, но ничего не гарантирую, да и причину сбоя всё равно надо знать...
скрипт остановился на 814 файле, на том же самом (M01_00.mat), оказывается он всегда на этом файле останавливается, прошлый раз я был не прав когда сказал, что всегда последний файл другой.
так вот, в "подопытной структуре" остались ещё папки Material3 с примерно сотней файлов *.mat.
насмотря на остановку скрипта, в лог он продолжал записывать, да так много, что script.log вырос до 45 мегабайт, я остановил скрипт. Касперский сходит с ума сейчас.
нужен этот лог?
я посмотрел в него и вот, что выяснил:
- оригинальный файл называется M01.mat
- обработка M01.mat начинается с середины script.log и ему присваивается индекс _00
- далее всем файлам M01.mat отличающимся по содержанию присваивается индекс от _00 до _99
- нашёл папку, на которой останавливается работа скрипта и дальше во всех папках присутствуют необработанные *.mat, наряду с большим количеством (относительно других) M01.mat
вывод, личный, так как не специалист:
скрипт обрабатывает 100 разных файлов M01.mat, затем повторяет операцию над последним файлом снова и снова, что и было замечано в script.log: обработчик поочерёдно пытается одному и тому же файлу присвоить индекс от _00 до _99, после неудачи операция повторяется.
скрипт обрабатывает 100 разных файлов M01.mat, затем повторяет операцию над последним файлом снова и снова, что и было замечано в script.log: обработчик поочерёдно пытается одному и тому же файлу присвоить индекс от _00 до _99, после неудачи операция повторяется. »вполне логично - выделение под номер только двух знаков предполагает, что одинаковых файлов будет не больше 100
а как тогда быть со скриптом? что нужно исправить в нём для добавления индекса с большим числом знаков?
а сколько знаков хватит?.. три?.. четыре?
на много время обработки вырастет если добавить:
три?.. четыре? »
или нет прямой зависимости?
в любом случае нужно не менее 4 символов!
а по-поводу скрипта проверяющего размер, действительно он ничем не быстрее? хочется всё таки максимально ускорить процесс.
на много время обработки вырастет если добавить »От количества знаков скорость не зависит... Кстати, почему такой странный способ определения папки назначения - два уровня вверх относительно текущего расположения? Не проще явно указать путь назначения?.. Скажем, каталог с батником.
почему такой странный способ определения папки назначения - два уровня вверх относительно текущего расположения? »
СХЕМА РАБОТЫ ТАКАЯ:
У МЕНЯ ЕСТЬ СТРУКТУРА:
<root>\extractor.exe
<root>\archives_container\сколь угодно глубокая и сложная структура, содержит архивы
<root>\script.bat
каждый архив содержит одинаковую структуру папок, но разные (в основном) имена файлов:
----- Назову условно структуру - STRUCT01 -----
Material3\содержит *.mat файлы
MatInst\содержит *.mat файлы
...
FolderLast\содержит *.tga файлы
РАБОТА СКРИПТА:
1 - распаковка архивов происходит в структуру:
<root>\_extracted\название_1-ого-архива\STRUCT01\файлы
<root>\_extracted\название_2-ого-архива\STRUCT01\файлы
...и т.д.
2 - теперь начинает работать скрипт по поиску и переносу файлов:
например он нашёл файл M01.mat в
<root>\_extracted\название_1-ого-архива\Material3\
и переносит его в папку (используя как раз 2 уровня вверх):
<root>\Material3\
получается у меня в корне будут все нужные мне папки (около 5-6) с файлами, вместо очень большого количества файлов в папке:
<root>\_extracted\
которая после завершения операции должна быть 0 байт
p.s.: надеюсь не слишком тупо написал, хотел как понятнее
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.