By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,205 Members | 994 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,205 IT Pros & Developers. It's quick & easy.

FileSystemWatcher raises Changed Twice....

P: n/a
ljh
Has anyone else noticed that the FileSystemWatcher raises the changed event
twice when a file is changed?

Do you have any idea why this is the case?

Jun 16 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
This has been asked several times before:
http://groups.google.com/groups?lnk=...mWatcher+twice

"ljh" <Re***@groups.please> wrote in message
news:cM*****************@bignews1.bellsouth.net...
Has anyone else noticed that the FileSystemWatcher raises the changed
event twice when a file is changed?

Do you have any idea why this is the case?

Jun 16 '06 #2

P: n/a
ljh
I saw those.....but there is no real solution listed there.

This seems to be another of .Nets gotcha's. Something that sounds great,
but doesn't really work out in real world programming.

The scary part for me is not the redundant changed messages so much as the
possibility of missing events. Microsoft's documentation says "The Windows
operating system notifies your component of file changes in a buffer created
by the FileSystemWatcher. If there are many changes in a short time, the
buffer can overflow. This causes the component to lose track of changes in
the directory, and it will only provide blanket notification. Increasing the
size of the buffer with the InternalBufferSize property is expensive, as it
comes from non-paged memory that cannot be swapped out to disk, so keep the
buffer as small yet large enough to not miss any file change events. To
avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories
properties so you can filter out unwanted change notifications. "
(http://msdn2.microsoft.com/en-us/lib...er(d=ide).aspx)

So changes can happen, as with the moving of a directory with many files
and/or subdirectories, that you may miss if your InternalBufferSize is not
set high enough. I say set it higher than you may need. After all, what is
more "expensive" than an app that does not perform as advertised?
"Lebesgue" <le******@gmail.com> wrote in message
news:uY*************@TK2MSFTNGP02.phx.gbl...
This has been asked several times before:
http://groups.google.com/groups?lnk=...mWatcher+twice

"ljh" <Re***@groups.please> wrote in message
news:cM*****************@bignews1.bellsouth.net...
Has anyone else noticed that the FileSystemWatcher raises the changed
event twice when a file is changed?

Do you have any idea why this is the case?


Jun 16 '06 #3

P: n/a
ljh
For more info on the InternalBufferSize property go to
http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx.

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
I saw those.....but there is no real solution listed there.

This seems to be another of .Nets gotcha's. Something that sounds great,
but doesn't really work out in real world programming.

The scary part for me is not the redundant changed messages so much as the
possibility of missing events. Microsoft's documentation says "The
Windows operating system notifies your component of file changes in a
buffer created by the FileSystemWatcher. If there are many changes in a
short time, the buffer can overflow. This causes the component to lose
track of changes in the directory, and it will only provide blanket
notification. Increasing the size of the buffer with the
InternalBufferSize property is expensive, as it comes from non-paged
memory that cannot be swapped out to disk, so keep the buffer as small yet
large enough to not miss any file change events. To avoid a buffer
overflow, use the NotifyFilter and IncludeSubdirectories properties so you
can filter out unwanted change notifications. "
(http://msdn2.microsoft.com/en-us/lib...er(d=ide).aspx)

So changes can happen, as with the moving of a directory with many files
and/or subdirectories, that you may miss if your InternalBufferSize is not
set high enough. I say set it higher than you may need. After all, what
is more "expensive" than an app that does not perform as advertised?
"Lebesgue" <le******@gmail.com> wrote in message
news:uY*************@TK2MSFTNGP02.phx.gbl...
This has been asked several times before:
http://groups.google.com/groups?lnk=...mWatcher+twice

"ljh" <Re***@groups.please> wrote in message
news:cM*****************@bignews1.bellsouth.net...
Has anyone else noticed that the FileSystemWatcher raises the changed
event twice when a file is changed?

Do you have any idea why this is the case?



Jun 16 '06 #4

P: n/a
ljh
Well, it seems that using an integer-sized value (directly or via a
declared integer variable) will NOT let you (or at least me) increase the
size of the InternalBufferSize value in a FileSystemWatcher object.

Whenever I use a statement like "FileSystemWatcher1.InternalBufferSize =
12288" I get an error message that says "The path is not of a legal form."
with a link
(http://msdn2.microsoft.com/en-us/lib...80,d=ide).aspx) to a
page that describes the error as "The exception that is thrown when one of
the arguments provided to a method is not valid."

This seems to be in direct contradiction to the sample code posted at
(http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx)
that states that you can use an integer to set the property to a multiple of
4096.

Am I just doing something stupid here?

"ljh" <Re***@groups.please> wrote in message
news:gx*****************@bignews1.bellsouth.net...
For more info on the InternalBufferSize property go to
http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx.

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
I saw those.....but there is no real solution listed there.

This seems to be another of .Nets gotcha's. Something that sounds great,
but doesn't really work out in real world programming.

The scary part for me is not the redundant changed messages so much as
the possibility of missing events. Microsoft's documentation says "The
Windows operating system notifies your component of file changes in a
buffer created by the FileSystemWatcher. If there are many changes in a
short time, the buffer can overflow. This causes the component to lose
track of changes in the directory, and it will only provide blanket
notification. Increasing the size of the buffer with the
InternalBufferSize property is expensive, as it comes from non-paged
memory that cannot be swapped out to disk, so keep the buffer as small
yet large enough to not miss any file change events. To avoid a buffer
overflow, use the NotifyFilter and IncludeSubdirectories properties so
you can filter out unwanted change notifications. "
(http://msdn2.microsoft.com/en-us/lib...er(d=ide).aspx)

So changes can happen, as with the moving of a directory with many files
and/or subdirectories, that you may miss if your InternalBufferSize is
not set high enough. I say set it higher than you may need. After all,
what is more "expensive" than an app that does not perform as advertised?
"Lebesgue" <le******@gmail.com> wrote in message
news:uY*************@TK2MSFTNGP02.phx.gbl...
This has been asked several times before:
http://groups.google.com/groups?lnk=...mWatcher+twice

"ljh" <Re***@groups.please> wrote in message
news:cM*****************@bignews1.bellsouth.net...
Has anyone else noticed that the FileSystemWatcher raises the changed
event twice when a file is changed?

Do you have any idea why this is the case?




Jun 16 '06 #5

P: n/a
ljh
The GOTCHA here seems to be that you MUST set the PATH property before you
can set/change the InternalBuffer property.

Don't ask me why......

"ljh" <Re***@groups.please> wrote in message
news:wT*****************@bignews1.bellsouth.net...
Well, it seems that using an integer-sized value (directly or via a
declared integer variable) will NOT let you (or at least me) increase the
size of the InternalBufferSize value in a FileSystemWatcher object.

Whenever I use a statement like "FileSystemWatcher1.InternalBufferSize =
12288" I get an error message that says "The path is not of a legal
form." with a link
(http://msdn2.microsoft.com/en-us/lib...80,d=ide).aspx) to a
page that describes the error as "The exception that is thrown when one of
the arguments provided to a method is not valid."

This seems to be in direct contradiction to the sample code posted at
(http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx)
that states that you can use an integer to set the property to a multiple
of 4096.

Am I just doing something stupid here?

"ljh" <Re***@groups.please> wrote in message
news:gx*****************@bignews1.bellsouth.net...
For more info on the InternalBufferSize property go to
http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx.

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
I saw those.....but there is no real solution listed there.

This seems to be another of .Nets gotcha's. Something that sounds
great, but doesn't really work out in real world programming.

The scary part for me is not the redundant changed messages so much as
the possibility of missing events. Microsoft's documentation says "The
Windows operating system notifies your component of file changes in a
buffer created by the FileSystemWatcher. If there are many changes in a
short time, the buffer can overflow. This causes the component to lose
track of changes in the directory, and it will only provide blanket
notification. Increasing the size of the buffer with the
InternalBufferSize property is expensive, as it comes from non-paged
memory that cannot be swapped out to disk, so keep the buffer as small
yet large enough to not miss any file change events. To avoid a buffer
overflow, use the NotifyFilter and IncludeSubdirectories properties so
you can filter out unwanted change notifications. "
(http://msdn2.microsoft.com/en-us/lib...er(d=ide).aspx)

So changes can happen, as with the moving of a directory with many files
and/or subdirectories, that you may miss if your InternalBufferSize is
not set high enough. I say set it higher than you may need. After all,
what is more "expensive" than an app that does not perform as
advertised?
"Lebesgue" <le******@gmail.com> wrote in message
news:uY*************@TK2MSFTNGP02.phx.gbl...
This has been asked several times before:
http://groups.google.com/groups?lnk=...mWatcher+twice

"ljh" <Re***@groups.please> wrote in message
news:cM*****************@bignews1.bellsouth.net...
> Has anyone else noticed that the FileSystemWatcher raises the changed
> event twice when a file is changed?
>
> Do you have any idea why this is the case?
>
>
>



Jun 16 '06 #6

P: n/a
ljh
If you use "*.doc" for the filter in your FileSystemWatcher control, you
will also recieve events for *.tmp files created and destroyed by Word.

Not really sure why....

"ljh" <Re***@groups.please> wrote in message
news:HY*****************@bignews1.bellsouth.net...
The GOTCHA here seems to be that you MUST set the PATH property before you
can set/change the InternalBuffer property.

Don't ask me why......

"ljh" <Re***@groups.please> wrote in message
news:wT*****************@bignews1.bellsouth.net...
Well, it seems that using an integer-sized value (directly or via a
declared integer variable) will NOT let you (or at least me) increase the
size of the InternalBufferSize value in a FileSystemWatcher object.

Whenever I use a statement like "FileSystemWatcher1.InternalBufferSize =
12288" I get an error message that says "The path is not of a legal
form." with a link
(http://msdn2.microsoft.com/en-us/lib...80,d=ide).aspx) to
a page that describes the error as "The exception that is thrown when one
of the arguments provided to a method is not valid."

This seems to be in direct contradiction to the sample code posted at
(http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx)
that states that you can use an integer to set the property to a multiple
of 4096.

Am I just doing something stupid here?

"ljh" <Re***@groups.please> wrote in message
news:gx*****************@bignews1.bellsouth.net...
For more info on the InternalBufferSize property go to
http://msdn2.microsoft.com/en-us/lib...ze(d=ide).aspx.

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
I saw those.....but there is no real solution listed there.

This seems to be another of .Nets gotcha's. Something that sounds
great, but doesn't really work out in real world programming.

The scary part for me is not the redundant changed messages so much as
the possibility of missing events. Microsoft's documentation says "The
Windows operating system notifies your component of file changes in a
buffer created by the FileSystemWatcher. If there are many changes in a
short time, the buffer can overflow. This causes the component to lose
track of changes in the directory, and it will only provide blanket
notification. Increasing the size of the buffer with the
InternalBufferSize property is expensive, as it comes from non-paged
memory that cannot be swapped out to disk, so keep the buffer as small
yet large enough to not miss any file change events. To avoid a buffer
overflow, use the NotifyFilter and IncludeSubdirectories properties so
you can filter out unwanted change notifications. "
(http://msdn2.microsoft.com/en-us/lib...er(d=ide).aspx)

So changes can happen, as with the moving of a directory with many
files and/or subdirectories, that you may miss if your
InternalBufferSize is not set high enough. I say set it higher than
you may need. After all, what is more "expensive" than an app that
does not perform as advertised?
"Lebesgue" <le******@gmail.com> wrote in message
news:uY*************@TK2MSFTNGP02.phx.gbl...
> This has been asked several times before:
> http://groups.google.com/groups?lnk=...mWatcher+twice
>
> "ljh" <Re***@groups.please> wrote in message
> news:cM*****************@bignews1.bellsouth.net...
>> Has anyone else noticed that the FileSystemWatcher raises the changed
>> event twice when a file is changed?
>>
>> Do you have any idea why this is the case?
>>
>>
>>
>
>



Jun 16 '06 #7

P: n/a

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
|I saw those.....but there is no real solution listed there.
|
| This seems to be another of .Nets gotcha's. Something that sounds great,
| but doesn't really work out in real world programming.
|

This has nothing to do with .NET, it's the way the FS signals events to the
OS and the way the FileSystemWatcher's underlying Win32 API
(ReadDirectoryChangesW) presents FS event info to the caller.

If you really want to know how FSW works check ReadDirectoryChangesW in
MSDN.

Willy.

Jun 16 '06 #8

P: n/a
ljh

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

"ljh" <Re***@groups.please> wrote in message
news:qv*****************@bignews1.bellsouth.net...
|I saw those.....but there is no real solution listed there.
|
| This seems to be another of .Nets gotcha's. Something that sounds
great,
| but doesn't really work out in real world programming.
|

This has nothing to do with .NET, it's the way the FS signals events to
the
OS and the way the FileSystemWatcher's underlying Win32 API
(ReadDirectoryChangesW) presents FS event info to the caller.


That's why I'd much rather be able to detect running instances of Word and
trap events like the saving of a file. Alas, that does not seem to be
possible with .Net.

I have seen tons of code that show how to create an instance of Word (or
Excel or Access or Outlook) and manipulate it programatically, but not one
that can show how to detect a running instance of Word and basically watch
what the user is doing with the files.

I am almost certain that this is not possible with managed code at all.
Another capability wiped out in the name of "safe" code.

Although, I suppose it has to be that way. If Microsoft really seeks to
save people (programmers) from themselves (which is a fool's game in any
industry), they have to take away the tools that they mis-use to do so.

You can't have "safe" and all-powerful in the same toolset. IMHO, it looks
like we're sacrificing power for "safety" with .Net.

Not a decision I would have made......but..........

Jun 17 '06 #9

P: n/a


"ljh" <Re***@groups.please> wrote in message
news:dS*****************@bignews1.bellsouth.net...
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:%2****************@TK2MSFTNGP04.phx.gbl...
| >
| > "ljh" <Re***@groups.please> wrote in message
| > news:qv*****************@bignews1.bellsouth.net...
| > |I saw those.....but there is no real solution listed there.
| > |
| > | This seems to be another of .Nets gotcha's. Something that sounds
| > great,
| > | but doesn't really work out in real world programming.
| > |
| >
| > This has nothing to do with .NET, it's the way the FS signals events to
| > the
| > OS and the way the FileSystemWatcher's underlying Win32 API
| > (ReadDirectoryChangesW) presents FS event info to the caller.
|
| That's why I'd much rather be able to detect running instances of Word and
| trap events like the saving of a file. Alas, that does not seem to be
| possible with .Net.
|
| I have seen tons of code that show how to create an instance of Word (or
| Excel or Access or Outlook) and manipulate it programatically, but not one
| that can show how to detect a running instance of Word and basically watch
| what the user is doing with the files.
|
| I am almost certain that this is not possible with managed code at all.
| Another capability wiped out in the name of "safe" code.
|

I said that FileSystemWatcher uses the underlying Win32 API
"ReadDirectoryChangesW", even if you use native code in you scenario you
will see two change events, Also ReadDirectoryChangesW is an API designed to
watch "Directory" changes not File changes, so is FSW.

The reason why see two events is because when Word saves a document, it
first save the old contents of the doc .file into a .tmp file (a rename),
after which he copies the new document contents into a .tmp file and renames
this .tmp back into your .doc file (a rename again). Another thing to keep
in mind is that Word maintains a lock file in the same directory as the .doc
file, this lock file has the same name as the .doc file with ~$ prepended.
This file is created and changed when words opens a doc file, it
'deletes'this lock file when the .doc file gets closed. So it's just a
matter of carefully selecting your NotifyFilters, and have an idea about
what exactly is done by the applicatins accesing the files in the watched
directory.

| Although, I suppose it has to be that way. If Microsoft really seeks to
| save people (programmers) from themselves (which is a fool's game in any
| industry), they have to take away the tools that they mis-use to do so.
|
| You can't have "safe" and all-powerful in the same toolset. IMHO, it
looks
| like we're sacrificing power for "safety" with .Net.
|

Again, .NET has nothing to do with this, but if you don't believe it, no one
stops you do it in native code.

Willy.

Jun 17 '06 #10

P: n/a
ljh

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:eQ****************@TK2MSFTNGP03.phx.gbl...


"ljh" <Re***@groups.please> wrote in message
news:dS*****************@bignews1.bellsouth.net...
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:%2****************@TK2MSFTNGP04.phx.gbl...
| >
| > "ljh" <Re***@groups.please> wrote in message
| > news:qv*****************@bignews1.bellsouth.net...
| > |I saw those.....but there is no real solution listed there.
| > |
| > | This seems to be another of .Nets gotcha's. Something that sounds
| > great,
| > | but doesn't really work out in real world programming.
| > |
| >
| > This has nothing to do with .NET, it's the way the FS signals events
to
| > the
| > OS and the way the FileSystemWatcher's underlying Win32 API
| > (ReadDirectoryChangesW) presents FS event info to the caller.
|
| That's why I'd much rather be able to detect running instances of Word
and
| trap events like the saving of a file. Alas, that does not seem to be
| possible with .Net.
|
| I have seen tons of code that show how to create an instance of Word (or
| Excel or Access or Outlook) and manipulate it programatically, but not
one
| that can show how to detect a running instance of Word and basically
watch
| what the user is doing with the files.
|
| I am almost certain that this is not possible with managed code at all.
| Another capability wiped out in the name of "safe" code.
|

I said that FileSystemWatcher uses the underlying Win32 API
"ReadDirectoryChangesW", even if you use native code in you scenario you
will see two change events, Also ReadDirectoryChangesW is an API designed
to
watch "Directory" changes not File changes, so is FSW.

The reason why see two events is because when Word saves a document, it
first save the old contents of the doc .file into a .tmp file (a rename),
after which he copies the new document contents into a .tmp file and
renames
this .tmp back into your .doc file (a rename again). Another thing to keep
in mind is that Word maintains a lock file in the same directory as the
.doc
file, this lock file has the same name as the .doc file with ~$ prepended.
This file is created and changed when words opens a doc file, it
'deletes'this lock file when the .doc file gets closed. So it's just a
matter of carefully selecting your NotifyFilters, and have an idea about
what exactly is done by the applicatins accesing the files in the watched
directory.

I understand what you are saying. The problem is that different systems may
raise different events in different orders depending upon what applications
on the systems (i.e. real time antivirus, antispyware, defraggers, etc.) are
accessing the files.

It is quite impossible (at least for me) to be able to take every scenario
and combination of software into consideration to determine exactly what has
transpired when a FS event is fired on any system.

What is needed in FileSystemWatcher (IMHO) is the ability to know which
process or exe is executing the FS function. This way, we could not only
filter on specific files, but also on specific programs that deal with those
files. For example, you could filter with "*.doc" and "winword.exe". Then,
if Word did anything to a DOC file, you'd know - without all of the
potentially confusing FS events that may be fired by God-only-knows-what
programs.
| Although, I suppose it has to be that way. If Microsoft really seeks to
| save people (programmers) from themselves (which is a fool's game in any
| industry), they have to take away the tools that they mis-use to do so.
|
| You can't have "safe" and all-powerful in the same toolset. IMHO, it
looks
| like we're sacrificing power for "safety" with .Net.
|

Again, .NET has nothing to do with this, but if you don't believe it, no
one
stops you do it in native code.


I will need to do COM interop to bring in old code to accomplish part of the
functionality that is not (as far as I can see) possible with .Net. I may
be missing something, but I do not see the ability in .Net to monitor
system-wide keystrokes or mouse events. Did I miss it somewhere?

Thanks for your response!
Jun 17 '06 #11

P: n/a
I will need to do COM interop to bring in old code to accomplish part of
the
functionality that is not (as far as I can see) possible with .Net. I may
be missing something, but I do not see the ability in .Net to monitor
system-wide keystrokes or mouse events. Did I miss it somewhere?

Thanks for your response!


You can do a limited set of system hooks including keyboard and mouse events
in .NET see:
http://www.codeproject.com/csharp/Gl...asp?msg=840940
Jun 17 '06 #12

P: n/a
ljh
Thanks for the link Lebesgue!

"Lebesgue" <le******@gmail.com> wrote in message
news:Oa***************@TK2MSFTNGP04.phx.gbl...
I will need to do COM interop to bring in old code to accomplish part of
the
functionality that is not (as far as I can see) possible with .Net. I
may be missing something, but I do not see the ability in .Net to monitor
system-wide keystrokes or mouse events. Did I miss it somewhere?

Thanks for your response!


You can do a limited set of system hooks including keyboard and mouse
events in .NET see:
http://www.codeproject.com/csharp/Gl...asp?msg=840940

Jun 17 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.