Непоследовательное поведение в командном файле для оператора - PullRequest
1 голос
/ 18 декабря 2011

Я сделал очень мало с пакетными файлами, но я пытаюсь отследить странную ошибку, с которой я столкнулся в устаревшей системе.

У меня есть несколько файлов .exe в определенной папке. Этот скрипт должен дублировать их с другим именем файла.

Код из командного файла

for %%i in (*.exe) do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe

(Примечание: исходная и целевая папки одинаковы)

Пример желаемого поведения:

File1.exe -->  Becomes -->  File1.exe.backup.exe
File2.exe -->  Becomes -->  File2.exe.backup.exe

А теперь позвольте мне сказать, что это не тот подход, который я выбрал бы. Я знаю, что есть другие (потенциально более прямые) способы сделать это. Я также знаю, что вы можете удивиться WHY на земле, мы заботимся о создании FileX.exe.backup.exe. Но этот скрипт работает уже много лет, и мне сказали, что проблема началась только недавно. Я пытаюсь точно определить проблему, а не переписывать код (даже если это будет тривиально).

Пример выхода с ошибками:

File1.exe.backup.exe
File1.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
etc...
File2.exe.backup.exe
File2.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe

Не зная ничего о пакетных файлах, я посмотрел на это и понял, что условие оператора for переоценивается после каждой итерации - создавая (почти) бесконечный цикл копирования (я могу видеть, что, в конце концов, копия не удастся, если имена станут слишком длинными).

Это объясняет поведение, которое я вижу. И когда очистил каталог, о котором идет речь, чтобы в нем был только оригинальный файл File1.exe и запустил скрипт, он выдал код ошибки. Проблема в том, что я не могу повторить поведение в другом месте!?!

Когда я создаю папку локально с несколькими файлами .exe и запускаю скрипт - я получаю ожидаемый результат. И да, если я запускаю его снова, я получаю один экземпляр File1.exe.backup.exe.backup.exe (и каждый раз, когда я запускаю его снова, длина увеличивается на единицу). Но я не могу заставить его войти в почти бесконечный цикл.

Это сводит меня с ума.

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

Документация, которую я могу найти в операторе 'for', не очень помогает, но все тесты, которые я запускал, показывают, что секция in (*.exe) оценивается только один раз в начале выполнения.

У кого-нибудь есть предложения по поводу того, что здесь может происходить?

Ответы [ 2 ]

1 голос
/ 25 января 2012

Копирование поддерживает символы подстановки также в целевом пути.Вы можете использовать

copy \\networkpath\folder\*.exe \\networkpath\folder\*.backup.exe
1 голос
/ 18 декабря 2011

Я согласен с комментарием Андрея М - похоже, он связан с Пакетный сценарий Windows 7 «For» Command Error / Bug

Следующее изменение должно решить проблему:

for /f "eol=: delims=" %%i in ('dir /b *.exe') do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe

Любой файл, который начинается с точки с запятой (очень маловероятно, но это может произойти), будет пропущен с EOL по умолчанию точки с запятой.Чтобы быть в безопасности, вы должны установить EOL для некоторого символа, который никогда не сможет начать имя файла (или любой путь).Вот почему я выбрал двоеточие - оно не может отображаться в имени папки или файла и может отображаться только после буквы диска.Так что всегда должно быть в безопасности.

...