FileSystemWatcher and file locking?

[intrepid_dw]

All:

I have a .NET 1.1 C#-based WinForms application that, as part of its
normal operation, creates and updates an XML-based log file. I expose a
method from a class to retrieve the text of the file via a
StringReader, which then puts the text into a DataView that is bound to
a DataGrid. This all works terrifically.

In testing the program, I discovered certain situations in which
activities were written to the log file at unexpected times and were
thus not updated to the UI. Rather than try to determine all the points
at which a change to the log file might occur that I might have missed,
I opted to spin off a thread to monitor the log file, with the intent
of refreshing the DataView upon each change notification.

I used a FileSystemWatcher to notify the thread of change events on the
file, and therein starts my problem. When I start the application, and
perform an action that gets logged, the notification occurs, but when I
go to fetch the updated text from the file I get an "IOException - File
is in use by another process."

Now perhaps my understanding of FileSystemWatcher semantics is naive or
incorrect, but the behavior almost makes me believe the FSW is actually
holding a *lock* on the file, which to me would be counterintuitive for
a "watcher" process. Up to the point of the failure, the application is
working - event occurs, log is written, notification fires, and the
call is made to retrieve the updated log text - and that's what
crashes.

If my understanding of how FSW works is wrong, or if this is such a
naive problem that I should have found another answer by more diligent
searching, my apologies in advance. (The problems I did find that
seemed similar actually departed in certain important ways) Any
thoughts or suggestions to resolve the problem would be appreciated.

-intrepid

[Greg Young]

My guess is that you are not opening the file as shared in when you open the
file for read/write. This would cause the file to be locked.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<in*********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

All:

I have a .NET 1.1 C#-based WinForms application that, as part of its
normal operation, creates and updates an XML-based log file. I expose a
method from a class to retrieve the text of the file via a
StringReader, which then puts the text into a DataView that is bound to
a DataGrid. This all works terrifically.

In testing the program, I discovered certain situations in which
activities were written to the log file at unexpected times and were
thus not updated to the UI. Rather than try to determine all the points
at which a change to the log file might occur that I might have missed,
I opted to spin off a thread to monitor the log file, with the intent
of refreshing the DataView upon each change notification.

I used a FileSystemWatcher to notify the thread of change events on the
file, and therein starts my problem. When I start the application, and
perform an action that gets logged, the notification occurs, but when I
go to fetch the updated text from the file I get an "IOException - File
is in use by another process."

Now perhaps my understanding of FileSystemWatcher semantics is naive or
incorrect, but the behavior almost makes me believe the FSW is actually
holding a *lock* on the file, which to me would be counterintuitive for
a "watcher" process. Up to the point of the failure, the application is
working - event occurs, log is written, notification fires, and the
call is made to retrieve the updated log text - and that's what
crashes.

If my understanding of how FSW works is wrong, or if this is such a
naive problem that I should have found another answer by more diligent
searching, my apologies in advance. (The problems I did find that
seemed similar actually departed in certain important ways) Any
thoughts or suggestions to resolve the problem would be appreciated.

-intrepid

[intrepid_dw]

Greg:

Thank you so much for taking the time to help.

In this particular case, I am not expressly opening the document as a
file - I'm opening it using the Load method of an XmlDocument instance.
When a transaction is logged, the XML document is opened, a transaction
added, then the document is written via the XmlDocument Save method
(back to the same filename).

Are the semantics of the Load method such that it does not open the
file shared? Or would it be better for me to expressly open the file
conventionally (shared), read it into a string, then use the string as
the parameter to the LoadXML method? This would allow me to ensure the
file is opened shared per your speculation.

Thanks again for your input.

-David

Greg Young wrote:

My guess is that you are not opening the file as shared in when you open the
file for read/write. This would cause the file to be locked.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<in*********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

All:

I have a .NET 1.1 C#-based WinForms application that, as part of its
normal operation, creates and updates an XML-based log file. I expose a
method from a class to retrieve the text of the file via a
StringReader, which then puts the text into a DataView that is bound to
a DataGrid. This all works terrifically.

In testing the program, I discovered certain situations in which
activities were written to the log file at unexpected times and were
thus not updated to the UI. Rather than try to determine all the points
at which a change to the log file might occur that I might have missed,
I opted to spin off a thread to monitor the log file, with the intent
of refreshing the DataView upon each change notification.

I used a FileSystemWatcher to notify the thread of change events on the
file, and therein starts my problem. When I start the application, and
perform an action that gets logged, the notification occurs, but when I
go to fetch the updated text from the file I get an "IOException - File
is in use by another process."

Now perhaps my understanding of FileSystemWatcher semantics is naive or
incorrect, but the behavior almost makes me believe the FSW is actually
holding a *lock* on the file, which to me would be counterintuitive for
a "watcher" process. Up to the point of the failure, the application is
working - event occurs, log is written, notification fires, and the
call is made to retrieve the updated log text - and that's what
crashes.

If my understanding of how FSW works is wrong, or if this is such a
naive problem that I should have found another answer by more diligent
searching, my apologies in advance. (The problems I did find that
seemed similar actually departed in certain important ways) Any
thoughts or suggestions to resolve the problem would be appreciated.

-intrepid

[Greg Young]

There is an overload that takes a stream
http://msdn2.microsoft.com/en-us/library/e48zttz7.aspx I would recommend
using this overload.

Cheers,

Greg

<in*********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

Greg:

Thank you so much for taking the time to help.

In this particular case, I am not expressly opening the document as a
file - I'm opening it using the Load method of an XmlDocument instance.
When a transaction is logged, the XML document is opened, a transaction
added, then the document is written via the XmlDocument Save method
(back to the same filename).

Are the semantics of the Load method such that it does not open the
file shared? Or would it be better for me to expressly open the file
conventionally (shared), read it into a string, then use the string as
the parameter to the LoadXML method? This would allow me to ensure the
file is opened shared per your speculation.

Thanks again for your input.

-David

Greg Young wrote:

>My guess is that you are not opening the file as shared in when you open
the
file for read/write. This would cause the file to be locked.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<in*********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegr oups.com...

All:

I have a .NET 1.1 C#-based WinForms application that, as part of its
normal operation, creates and updates an XML-based log file. I expose a
method from a class to retrieve the text of the file via a
StringReader, which then puts the text into a DataView that is bound to
a DataGrid. This all works terrifically.

In testing the program, I discovered certain situations in which
activities were written to the log file at unexpected times and were
thus not updated to the UI. Rather than try to determine all the points
at which a change to the log file might occur that I might have missed,
I opted to spin off a thread to monitor the log file, with the intent
of refreshing the DataView upon each change notification.

I used a FileSystemWatcher to notify the thread of change events on the
file, and therein starts my problem. When I start the application, and
perform an action that gets logged, the notification occurs, but when I
go to fetch the updated text from the file I get an "IOException - File
is in use by another process."

Now perhaps my understanding of FileSystemWatcher semantics is naive or
incorrect, but the behavior almost makes me believe the FSW is actually
holding a *lock* on the file, which to me would be counterintuitive for
a "watcher" process. Up to the point of the failure, the application is
working - event occurs, log is written, notification fires, and the
call is made to retrieve the updated log text - and that's what
crashes.

If my understanding of how FSW works is wrong, or if this is such a
naive problem that I should have found another answer by more diligent
searching, my apologies in advance. (The problems I did find that
seemed similar actually departed in certain important ways) Any
thoughts or suggestions to resolve the problem would be appreciated.

-intrepid

[intrepid_dw]

Greg:

This looks like an excellent potential solution for this problem.

Thank you again for your assistance.

-David

Greg Young wrote:

There is an overload that takes a stream
http://msdn2.microsoft.com/en-us/library/e48zttz7.aspx I would recommend
using this overload.

Cheers,

Greg

<in*********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

Greg:

Thank you so much for taking the time to help.

In this particular case, I am not expressly opening the document as a
file - I'm opening it using the Load method of an XmlDocument instance.
When a transaction is logged, the XML document is opened, a transaction
added, then the document is written via the XmlDocument Save method
(back to the same filename).

Are the semantics of the Load method such that it does not open the
file shared? Or would it be better for me to expressly open the file
conventionally (shared), read it into a string, then use the string as
the parameter to the LoadXML method? This would allow me to ensure the
file is opened shared per your speculation.

Thanks again for your input.

-David

Greg Young wrote:

My guess is that you are not opening the file as shared in when you open
the
file for read/write. This would cause the file to be locked.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<in*********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
All:

I have a .NET 1.1 C#-based WinForms application that, as part of its
normal operation, creates and updates an XML-based log file. I expose a
method from a class to retrieve the text of the file via a
StringReader, which then puts the text into a DataView that is bound to
a DataGrid. This all works terrifically.

In testing the program, I discovered certain situations in which
activities were written to the log file at unexpected times and were
thus not updated to the UI. Rather than try to determine all the points
at which a change to the log file might occur that I might have missed,
I opted to spin off a thread to monitor the log file, with the intent
of refreshing the DataView upon each change notification.

I used a FileSystemWatcher to notify the thread of change events on the
file, and therein starts my problem. When I start the application, and
perform an action that gets logged, the notification occurs, but when I
go to fetch the updated text from the file I get an "IOException - File
is in use by another process."

Now perhaps my understanding of FileSystemWatcher semantics is naive or
incorrect, but the behavior almost makes me believe the FSW is actually
holding a *lock* on the file, which to me would be counterintuitive for
a "watcher" process. Up to the point of the failure, the application is
working - event occurs, log is written, notification fires, and the
call is made to retrieve the updated log text - and that's what
crashes.

If my understanding of how FSW works is wrong, or if this is such a
naive problem that I should have found another answer by more diligent
searching, my apologies in advance. (The problems I did find that
seemed similar actually departed in certain important ways) Any
thoughts or suggestions to resolve the problem would be appreciated.

-intrepid