У меня есть сервер 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, и это все равно произошло. Я считаю, что каталог C: \ work, который является общим ресурсом, который на самом деле является диском E:, подключенным как каталог к C: \ work, одновременно доступен 2 удаленным хостам, и, возможно, это вызывает блокировку каталога первым хост. Раньше этого не происходило до того, как я смонтировал E: в рабочий каталог. Существуют ли известные проблемы с блокировкой файлов и томами, смонтированными как каталоги?
Оказывается, проблема не в VMware Tools. Более вероятно, что эта проблема была вызвана службой Windows Application Experience, но я не уверен. В конечном итоге я решил проблему, добавив виртуальный диск и создав новый общий ресурс, а затем направив сборку на этот общий ресурс. Если на этапе сборки остается открытый дескриптор для этого общего ресурса, он не повлияет на последующий шаг, который больше не ссылается на этот общий ресурс (ранее все выполнялось из того же общего ресурса, поэтому при наличии открытого дескриптора файловые операции завершатся ошибкой).