如果应用程序由于未处理的异常或其他原因而崩溃，FileStream会发生什么？

Question

I have an application made to be accessed by multiple users at the same time and leverages an API that uses OAuth 2.0. The application depends on a single file that stores information such as the access token for making API calls. When an access token expires, the app must go through the process of getting a new one via the API and save it to the file. If multiple people attempt to do this at once, only one of those tokens will work.

The proposed solution was to open a FileStream to a specific file with only Read access when a user starts the process of getting a new token. That FileStream will then be disposed of when the process ends. The app will check if that file can be written to. If it cannot, that means someone else is getting a new token and that instance of the application must wait until the new token has been obtained.

If the application crashes during that process, what happens to the lock on that file? I assume the operating system frees that lock, but what if the crash happened due to something in unmanaged code or something else that wasn't an unhandled exception?

Answer 1

ok the thing is when you open a file it has these modes. and whenever you open a file a handler is created and pass it to you and you assign it to a ref

1. reading
2. writing
3. both of them
4. neither of those

An open file that is not shared it cannot be open in the same caller application or other until it closed by caller app and it's exclusive access.

If file open in sharing mode the system compares the requested access and sharing modes to those specified when the file was opened. If you specify an access or sharing mode that conflicts with the modes specified in the previous call, open file fails.

our application experiences a hard crash your managed code's resources will not get cleared by application or it will not try to recover the things . basically all the GC things of your code will not run.but the operating system will still attempt to clean up after you. This solves the problem of unreleased memory, handles, and other system objects so does your FileStream handlers

My best guess is that if file is in shared mode lock on that file will be release by the OS cleanup after your app crashes. cus your app's logic will never reach to that state again.

this is also true with un-managed code segments cus it directly calling the Managed OS api and the OS handlers will create and if that os handlers in a crash those handlers will be takeen care by OS it self.

this is how Windows 10 prevent memory location hijacking on it's system file locations.

Answer 2

If you are using any unmanaged code and exception comes in middle of that. System will leave the file in use. That's why in our code it is always a best practice to use either 'using' block for that OR try {} catch {} and finally {}.

using statement will make sure to release the resources on it's own while you need to explicitly release them in try , catch and finally block, once the object goes out of scope.