L
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?
twice when a file is changed?
Do you have any idea why this is the case?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
L
Lebesgue
This has been asked several times before:
http://groups.google.com/groups?lnk=hpsg&hl=en&q=FileSystemWatcher+twice
http://groups.google.com/groups?lnk=hpsg&hl=en&q=FileSystemWatcher+twice
L
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/library/system.io.filesystemwatcher(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?
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/library/system.io.filesystemwatcher(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?
L
ljh
For more info on the InternalBufferSize property go to
http://msdn2.microsoft.com/en-us/library/system.io.filesystemwatcher.internalbuffersize(d=ide).aspx.
http://msdn2.microsoft.com/en-us/library/system.io.filesystemwatcher.internalbuffersize(d=ide).aspx.
L
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/library/ms242197(VS.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/library/system.io.filesystemwatcher.internalbuffersize(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?
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/library/ms242197(VS.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/library/system.io.filesystemwatcher.internalbuffersize(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?
L
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......
can set/change the InternalBuffer property.
Don't ask me why......
L
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....
will also recieve events for *.tmp files created and destroyed by Word.
Not really sure why....
W
Willy Denoyette [MVP]
|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.
|
| 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.
L
ljh
Willy Denoyette said:|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..........
W
Willy Denoyette [MVP]
|
| | >
| > | > |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.
| | >
| > | > |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.
L
ljh
Willy Denoyette said:|
| | >
| > | > |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!
L
Lebesgue
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/GlobalSystemHook.asp?msg=840940
L
ljh
Thanks for the link Lebesgue!
Lebesgue said:You can do a limited set of system hooks including keyboard and mouse
events in .NET see:
http://www.codeproject.com/csharp/GlobalSystemHook.asp?msg=840940
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.