streamwriter and streamreader and closing files

[Jimbo]

After I read or write a file with streamreader and streamwriter and I close
it with the Close method, does that automatically let go of the file so that
any other process can modify it?
In my form, I read from a small configuration file with streamreader and
close it with streamreader.Close(). In this same event, when I open it for
modification with a streamwriter, it tells me the file's being used by
another process.

Thanks again.

 

[Alfred Taylor]

With my limited knowledge of the garbage collector, I'm going to
venture an educated guess that no, the file is not immediately
released.

From what I understand, whenever you call .Close() you're essentially
telling the GC that you don't want this file anymore and the GC will
release it when it gets around to it. (which is not necessarily
immediately)

And just a tip that I've found handy, for objects which implement
IDipsose (such as streamwriter/reader), you can use the using
statement which will automatically displose the stream for you.

that way you don't have to remember to .Close()

using(StreamReader sr = new StreamReader("myfile.txt"))
{
// do my stuff with the stream, and no matter if an exception
occurs, i manually "return", or i reach the end of the block, my
stream gets disposed for me.
}

 

[VM]

Hi,
Thanks for the info. I tried that and it works great. Like you said,
apparently the file's not released immediately when you use Close(). But I
switched it your way (and eliminated all the Close() ) and now it doesn't
give me the problem anynore.

Thanks.

 

[Einar Høst]

Hi,
Thanks for the info. I tried that and it works great. Like you said,
apparently the file's not released immediately when you use Close(). But I
switched it your way (and eliminated all the Close() ) and now it doesn't
give me the problem anynore.

Thanks.

According to Richter's (brilliant) book, the IL produced from using the
"using" keyword like this:

using (FileStream fs = new FileStream("myfile.txt", FileMode.Open)
{
// do something useful...
}

is identical to

FileStream fs = null;
try
{
fs = new FileStream("myfile.txt", FileMode.Open);
// do something useful...
}
finally
{
if (fs != null) ((IDisposable) fs).Dispose();
}

It's just syntactic sugar to make the code more readable. The important part
is that the code inside finally is guaranteed to be called, even if an
exception should occur. Note by the way that Dispose is called, not Close.
The reason is that Dispose is part of IDisposable (making "using" possible),
wheras Close is not. However, as far as I know, Close just calls Dispose
anyways.

Regards,
Einar

 

[Jeffrey Tan[MSFT]]

Hi Jimbo,

Is your problem resolved?

Just as Einar said, the using Statement in C# is the same as calling
IDisposable.Dispose in finally block.
IDisposable.Dispose method will explicitly release and free the unmanaged
resources, such as files, streams, and handles held by an instance of the
class.
For more detailed information, please refer to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemIDisposableClassDisposeTopic.asp

If you have any further concern, please feel free to post, I will help you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Jon Skeet [C# MVP]]

With my limited knowledge of the garbage collector, I'm going to
venture an educated guess that no, the file is not immediately
released.

From what I understand, whenever you call .Close() you're essentially
telling the GC that you don't want this file anymore and the GC will
release it when it gets around to it. (which is not necessarily
immediately)

No - calling Close on a StreamWriter (etc) is effectively the same as
calling Dispose. Otherwise Close() wouldn't do anything at all - the GC
doesn't need to be told that you don't want this file, it'll just
notice (eventually) after the object can no longer be referenced, and
then the finalizer will run at some point.

 

[SM]

Try using Thread.Sleep(200) before your second call...