У меня есть сервер Windows 2008 R2 X64, работающий на Vmware ESXi. Изначально он работал на Hyper-V, но с тех пор я преобразовал VHD в VMDK и перешел на ESXi. Я также установил VMware Tools. Этот сервер — наш сервер непрерывной интеграции TeamCity, выполняющий ночные сборки пакетов программного обеспечения, которые разрабатывает моя компания. После переезда иногда некоторые файлы, которые процесс сборки должен удалить, не удаляются из-за сообщения «Файл используется другим процессом». Мы пытаемся удалить файлы с помощью команды CMD del. Иногда это срабатывает, иногда нет. Я запустил монитор процессов с путем к каталогу, в котором происходят сбои, в качестве фильтра PATH (PATH содержит C:\work ). Я вижу МНОГО операций vmtoolsd.exe Createfile, FileSystemControl и CloseFile, происходящих в быстрой последовательности, неоднократно. Кто-нибудь слышал о том, что инструменты Vmware вызывают блокировки файловой системы на гостевых системах Windows?
Мне пока не удалось зафиксировать с помощью procmon момент, когда это действительно происходит, но я планирую попробовать.
Также из-за нехватки места этот каталог C:\work был воссоздан путем переименования его в C:\work-old, добавления второго виртуального диска E:\ и монтирования диска в каталог C:\work, а затем копирования содержимого C:\work-old в недавно смонтированный C:\work. Я вижу, что Vmware Tools постоянно выполняет FSCTL_Get_Reparse_Point на C:\work.
ОБНОВЛЯТЬ: Я отключил службу VMware tools вчера вечером, но это все равно произошло. Я полагаю, что к каталогу C:\work, который является общим ресурсом, который на самом деле является диском E:, смонтированным как каталог в C:\work, обращаются одновременно два удаленных хоста, и, возможно, это вызывает блокировку каталога первым хостом. Раньше этого не происходило, пока я не смонтировал E: в рабочий каталог. Известны ли какие-либо проблемы с блокировкой файлов и томами, смонтированными как каталоги?
решение1
Оказывается, проблема была вызвана не VMware Tools. Скорее всего, проблема была вызвана службой Windows Application Experience, но я не уверен. В конечном итоге я решил проблему, добавив виртуальный диск и создав новый ресурс, а затем указав сборке искать этот ресурс. Если шаг сборки оставляет открытый дескриптор для этого ресурса, это не повлияет на последующий шаг, который больше не ссылается на этот ресурс (ранее все делалось из того же ресурса, поэтому при наличии открытого дескриптора файловые операции завершались ошибкой).