Машина сохраняет файл существует / блокируется при отключении питания на стороне клиента

Question

Наше приложение работает на клиентском сервере A и создает файл на файловом сервере server 2008 R2, используя:

CreateFile(LockFileName,
                  GENERIC_READ or GENERIC_WRITE,
                  FILE_SHARE_READ, nil,
                  CREATE_ALWAYS,
                  FILE_FLAG_WRITE_THROUGH or FILE_FLAG_DELETE_ON_CLOSE,
                  0);

Клиент тестирует аварийную ситуацию, выключает «сервер А» и выключает его. Они сообщают, что наше приложение, работающее на «сервере B» с тем же именем файла и с тем же фрагментом кода выше, перестает работать (т. Е. Файл продолжает существовать) не менее 15 минут, пока, как мы полагаем, они не перейдут в папку, содержащую файл, в Проводник Windows, в этот момент файл удаляется автоматически.

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

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

Answer 1

[...] если создатель сервера ушел, должны ли дескрипторы быть освобождены и файл был удален автоматически?

В конечном счете, да, но не сразу.Поскольку вы используете Windows Server 2008 R2 (и, следовательно, SMBv2, обратите внимание, что я предполагаю, что и сервер, и клиент работают на Windows Server 2008 R2), клиент запросит дескриптор файла durable .В соответствии со спецификацией SMBv2 , разделами 3.3.6.2 и 3.3.7.1, сервер должен запустить долговременный таймер открытого мусора (по умолчанию для Windows Server установлено значение 16 минут).По истечении таймера сервер должен проверить все открытые дескрипторы и закрыть те, которые не были возвращены клиентом.

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

Теперь предположим, что другой клиент пытается открыть файл, пока работает длительный тайм-аут /Сервер по-прежнему считает файл открытым первым клиентом.Затем предполагается отправить уведомление о разрыве блокировки (раздел 2.2.23.1) клиенту, который первоначально открыл файл.Поскольку клиент не может ответить (он был уничтожен), сервер будет ожидать истечения времени ожидания подтверждения прерывания операции (раздел 3.3.2.1, по умолчанию 35 секунд), прежде чем он предоставит новому клиенту доступ к файлу.

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

Так должна вести себя система.Относительно того, почему вы испытываете описанные проблемы, я не могу сказать.Я не удивлюсь, если вы наткнетесь на ошибку в реализации Fileserver в Win Server 2008. Я постараюсь устранить проблему, используя инструменты, упомянутые в других ответах (procmon действительно хорош), и Wireshark также очень помогает..

Answer 2

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

До тех пор, пока вы фактически не попытаетесь воздействовать на файловый дескриптор.Внезапно сервер замечает, что узел дескриптора файла пропал, потому что он пытается инициировать связь с указанным узлом.Как только он это осознает, дескриптор файла принудительно закрывается.

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

Обновление

Sysinternals , купленное Microsoft несколько лет назад, имеет замечательный инструмент под названием Process Explorer это позволяет вам искать дескрипторы открытых файлов процессов.Это может быть полезно при определении того, какие программы обновляют дескриптор файла.

Sysinternals также имеет Process Monitor , который позволяет просматривать в режиме реального временикак программы действуют на дескрипторы файлов.Это может быть еще одна полезная программа для устранения проблемы.

Редактировать: О, и если вы действительно хотите повеселиться, есть Ручка тоже.

Answer 3

Для меня это пока не проблема. Или тот, который не может быть обработан за пределами программирования Microsoft И тот, который имеет побочные эффекты при обращении. В основном вы должны учитывать небольшие нарушения связи между клиентом и сервером и оптимизировать сетевой трафик, поэтому сервер не может постоянно обмениваться пакетами с клиентом просто для того, чтобы посмотреть, все ли еще клиент.

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

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

Как сервер узнает?

И почему просмотр файла приводит к его удалению?

P9 Возможно, именно чтение вызвало тайм-аут обновления, поэтому - в конце - это вызвало определенное поведение (DELETE_ON_CLOSE).

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