Процесс не может получить доступ к файлу, так как он используется другим процессом.

Иногда я получаю это сообщение в регулярном выводе одного из своих запусков через CMD-скрипт:

«Процесс не может получить доступ к файлу, потому что он используется другим процессом.»

Я знаю, что могу использовать программы для активного мониторинга процессов, блокирующих файлы, но этот скрипт работает в фоновом режиме. Также: блокировки действительно существуют, но все они очень короткие ( < 1 секунда ).

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

Итак, мой вопрос: как вы ретроспективно можете выяснить, какой файл был заблокирован, основываясь на этой информации?

Было бы здорово, если бы сообщение об ошибке отображало имя файла, который оно находит в блокировке.

Вопрос важен, поскольку «Процесс не может получить доступ к файлу, потому что он используется другим процессом.» обозначает, что целостность данных была потеряна.

Скорее всего, причина заключается в сбоях в самом CMD-скрипте. Имейте в виду, что в терминах CMD любой (...) не является средством для лексической структуры скрипта, а подразумевает вызов дополнительного экземпляра CMD! То же самое относится к подпрограммам call :Label ... goto :EOF. Это следует понимать как: запускаются параллельные процессы. По крайней мере на многопроцессорной машине это также означает, что эти экземпляры CMD не выполняются точно в соответствии с последовательным порядком управляющего пакетного скрипта. В частности, это касается их вывода в файловую систему. Даже если процессор пакетного скрипта ожидает возврата от дополнительного экземпляра CMD, очевидно, он не знает, когда данные будут записаны в файл и будет ли освобожден соответствующий файл. Возможно, процессор пакетного скрипта держит файл открытым с намерением ускорить последовательные операции добавления, но не всегда удается правильно угадать, какой экземпляр CMD станет следующим писателем. Механизм для явной очистки буфера записи и освобождения файла отсутствует.

• «Процесс не может получить доступ …» предупреждения скорее всего относятся только к операциям записи. Любой тест на доступность с использованием операции чтения не поможет.
• Так как предупреждения указывают на то, что файл, о котором идет речь, записывается неполностью И записанные строки не находятся в желаемом порядке, ответ на исходный вопрос таков:

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

set bFile=locktest.B.txt
del /Q %bFile%
for /L %%i in (0,1,%cBMax%) do @(
    echo { %tFile%
    echo echo !TIME! B_%%i 
    echo !TIME! B_%%i 1>>%tFile%
    echo } %tFile%
)>>%bFile% 2>&1

и вы получите это [если вы просите о DRY, сравните “производительность” ниже].

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

• Как избежать коллизий записи?

• Как поймать предупреждение «Процесс не может получить доступ …»?

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

@ 2>&1 (...)|for /F "tokens=1*" %%t in ('more') do @if "%%t"=="The" echo !TIME! %%t %%u 

Это показывает, что фильтрация нарушает отложенное расширение переменных, поэтому мы не можем сделать больше, чем преобразовать предупреждение, которое мы хотим поймать, в фатальную (нарушающую) ошибку с помощью чего-то вроде goto :EOF, или просто дублировать само предупреждение. Тем не менее, на этом этапе вы можете быть уверены, что вы пытаетесь записать в %tFile%, что вы знаете без необходимости отложенного расширения переменных из окружения. Таким образом, без потери целостности данных в уме, ответ на исходный вопрос таков:

@ 2>&1 (...)|for /F "tokens=1" %%t in ('more') do @if "%%t"=="The" echo %~n0[B]: cannot append to %tFile% 

Недавно у меня произошла эта ошибка в командной строке в Windows 10 v1903. Ошибка отображается в консоли для конкретного имени файла, которое является ZeroBytes.lst. Я перенаправляю текстовый вывод в это имя файла на виртуальный диск, созданный ImDisk. Перенаправление этого вывода на любой другой диск и/или папку (тот же виртуальный диск) не вызывает ошибок. Кроме того, процесс отображает эту ошибку немедленно, но продолжает работать и завершает работу с errorlevel = 0, когда он должен установить errorlevel GTR 0. Короче говоря, сам процесс только отображает ошибку, но не устанавливает ее. Это происходит, когда я перенаправляю вывод, используя > R:\WDr\ZeroBytes.lst. Любое другое имя файла работает без ошибок в R:\WDr, и ZeroBytes.lst работает без ошибок в любой другой папке на диске R.

Я реализовал обходной путь следующим образом: ” >R:\WDr\ZeroBytes.lst 2>&1″

Похоже, вы искали детали, так что надеюсь, это поможет.