FileStream.close() does not free file for other processes

Question

I have Following Code in a Page_Load called function. When the Page is loaded the first time after starting Visual Studio, everything works out fine.
But any other opening call to the File after that returns IOException: "File is in use by another process", even when directly opening the File in VisualStudio Solution this Error is returned(of course not as Exception)

FileStream mailinglist_FileStream = new FileStream(@"\foobarFile.txt", FileMode.Open);
PeekingStreamReader mailinglist_Reader = new PeekingStreamReader(mailinglist_FileStream);
//Do some stuff with the file
mailinglist_FileStream.Close();
mailinglist_Reader.Close();
mailinglist_Reader.Dispose();
mailinglist_FileStream.Dispose();

Why is the file still locked? and why does fully restarting Visual Studio reset the File? when checking file-Properties it says:

Build Action: Content
Copy to output directory: do not Copy

I am only reading this File. can i do something similiar to adLockOptimistic, so that multiple processes can access the File?

Answer 1

Why is the file still locked? and why does fully restarting Visual Studio reset the File? when checking file-Properties it says [...] I don't know why the file is still locked: probably because your code fails before the stream is closed/disposed.

About "why fully restarting Visual Studio [...]": because you may be using IIS Express or ASP.NET Dev Server whose are closed when you close the IDE, so locks on files are released since the process holding the locks is no longer running.

And about "why is the file still locked?[...]" it could be because the file stream isn't closed because sometimes the thread may not end successfully and the locks aren't released.

As other answer said, check how using block may avoid that IDisposable objects wouldn't be disposed:

// FileShare.ReadWrite will allow other processes 
// to read and write the target file even if other processes 
// are working with the same file
using var mailinglist_FileStream = new FileStream(@"\foobarFile.txt", FileMode.Open, FileShare.ReadWrite);
using var mailinglist_Reader = new PeekingStreamReader(mailinglist_FileStream);
      // Do your stuff. Using blocks will call Dispose() for 
      // you even if something goes wrong, as it's equal to a try/finally! 

I am only reading this File. can i do something similiar to adLockOptimistic, so that multiple processes can access the File?

Yes, take a look at File.Open method and FileShare enumeration:

• File.Open: http://msdn.microsoft.com/en-us/library/y973b725.aspx
• FileShare enum: http://msdn.microsoft.com/en-us/library/system.io.fileshare.aspx

Answer 2

Learn to use using:

using (FileStream fileStream = File.Open(@"C:\somefile", FileMode.Open, FileAccess.Read))
{
    ...
}

The using construct ensures that the file will be closed when you leave the block even if an exception is thrown.

Your problem might not be here, but somewhere else in your code. You'll have to go through all your code and look for places where you have opened files but not put it inside a using statement.

Answer 3

Try using using blocks, it may not fix your lock problem, but it is better form for disposable objects.

using (FileStream mailinglist_FileStream = new FileStream(@"\foobarFile.txt", FileMode.Open))
{
    using (PeekingStreamReader mailinglist_Reader = new PeekingStreamReader(mailinglist_FileStream))
    {
        ...            
    }
}

Also, try closing mailinglist_Reader before mailinglist_FileStream.

Answer 4

An old question but unfortunately the given answers can be not applicable to the question.

The problem specifically in Windows lies in two aspects of Windows behavior:

a) when the handle to the file, opened for writing, is closed, the Microsoft Antimalware Service opens the file to check the newly written data for malware;

b) the OS itself keeps the file opened for some time after all handles to it are closed. This time can be from seconds to many minutes depending on the nature of the file and other factors.

We saw this problem many times in our products and had to provide special support for this case - our kernel-mode attempts to close the file as soon as the last handle to it is closed.