В Microsoft объяснили ситуацию с давней ошибкой блокировки файлов в Windows

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

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

Марк Руссинович, технический директор Azure и технический эксперт Microsoft, недавно объяснил, почему это давнее поведение Windows всё ещё встречается. Сам он в первый раз столкнулся с этой проблемой в 1990-х годах, и это в конечном итоге подтолкнуло его к созданию инструментов, которые могли бы показать, что Windows скрывает от пользователей.

Обычно сбой связана с так называемым файловым дескриптором.

Файловый дескриптор — это ссылка Windows, которая отслеживает, какой процедура использует файл. Когда приложение открывает документ, видео, DLL-файл, изображение, архив или другой файл, Windows создаёт дескриптор, чтобы управлять доступом к этому файлу. Windows блокирует исключение или переименование, пока существует дескриптор. Причина — безопасность данных. Если Windows даёт возможность пользователям удалять или заменять файл, пока другая программа всё ещё использует его, программа может зависнуть или информация могут быть повреждены.

Закрытие видимого приложения не всегда освобождает все дескрипторы, связанные с файлом. Руссинович отметил, что некоторое количество фоновых действий могут удерживать файл заблокированным после этого.

Одной из распространённых причин является антивирусное сканирование. Программное обеспечение безопасности может открывать файл в фоновом режиме, проверяя его на наличие угроз. Даже если пользователь уже закрыл Word, Media Player, проводник или другое видимое приложение, антивирусный процесс всё ещё может удерживать файл открытым.

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

Самый запутанный случай связан с DLL-файлами. Если Windows загружает файл как динамически подключаемую библиотеку, он может не отображаться как обычный открытый дескриптор файла. Вместо этого Windows отображает его в хранилище процесса.

Это означает, что обычные проверки дескрипторов файлов могут не сразу выявить причину. В случаях, связанных с DLL-файлами, пользователям может потребоваться завершить работу всего приложения, в памяти которого загружен файл.

Руссинович создал средство командной строки Handle после того, как сам столкнулся с этой проблемой в 1990-х годах.

Handle является частью пакета Microsoft Sysinternals, набора расширенных утилит для устранения неполадок Windows. Инструмент может показать, какой процесс открыл файл, включая имя процесса и идентификатор процесса.

Process Explorer предлагает графическую альтернативу, которая может искать дескрипторы и DLL-файлы, что упрощает поиск процесса, заблокировавшего файл, без использования инструментов командной строки. Равным образом существуют более современные и удобные варианты, такие как PowerToys File Locksmith, который даёт возможность пользователям щёлкнуть правой кнопкой мыши по файлу, чтобы увидеть, какие процессы его используют, и быстро завершить их перед повторной попыткой удаления или переименования.

Для обычных пользователей это самая простая современная альтернатива Sysinternals. Она переносит ту же основную идею устранения неполадок в более простой интерфейс.

Руссинович также предложил обходной путь для некоторых случаев с заблокированными файлами: сначала переименовать их. В некоторых ситуациях Windows может позволить пользователям переименовать заблокированный файл, даже если не разрешает немедленное удаление. После переименования пользователи могут поместить новую копию с исходным именем в ту же папку. Старый файл можно удалить позже.

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

Ранее Руссинович рассказал об успешной реконструкции и поиске уязвимостей в старом коде с помощью ИИ. Он привёл в качестве примера собственный исходник Apple II 40-летней давности. Руссинович поручил Claude Opus 4.6 проверить код. Программа декомпилировала машинный язык и обнаружила некоторое количество проблем безопасности, в том числе случай «скрытого некорректного поведения».