Что происходит с FileStream в случае сбоя приложения из-за необработанного исключения или иным образом?

Question

У меня есть приложение, созданное для одновременного доступа нескольких пользователей, и использующий API, который использует OAuth 2.0.Приложение зависит от одного файла, в котором хранится такая информация, как токен доступа для выполнения вызовов API.Когда токен доступа истекает, приложение должно пройти через процесс получения нового через API и сохранить его в файл.Если несколько человек попытаются сделать это одновременно, будет работать только один из этих токенов.

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

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

Answer 1

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

1. чтение
2. запись
3. оба из них
4. ни один из этих

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

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

наше приложение испытывает серьезный сбой, ресурсы вашего управляемого кода не будут очищены приложением или не будут пытатьсячтобы восстановить вещи.в основном все компоненты GC вашего кода не будут работать. Но операционная система все еще будет пытаться очистить после вас.Это решает проблему невыпущенной памяти, дескрипторов и других системных объектов, так же, как и ваши обработчики FileStream

Мое лучшее предположение состоит в том, что если файл находится в режиме совместного использования, блокировка этого файла будет снята после очистки ОС после вашего приложения.сбои.Потому что логика вашего приложения никогда не достигнет этого состояния.

это также верно для сегментов неуправляемого кода, так как он напрямую вызывает API управляемой ОС, и обработчики ОС будут создавать, и если эти обработчики ОС будут аварийно завершать работу.эти обработчики сами позаботятся об ОС.

это то, как Windows 10 предотвращает захват области памяти в местах ее системных файлов.

Answer 2

Если вы используете какой-либо неуправляемый код, и в середине этого процесса возникает исключение.Система оставит файл в использовании.Вот почему в нашем коде всегда лучше использовать блок 'using' для этого ИЛИ try {} catch {} и, наконец, {}.

с помощью оператора обязательно освободит ресурсы самостоятельнов то время как вам нужно явно освободить их в блоки try, catch и finally, как только объект выйдет из области видимости.