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? 12 4196
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?
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?
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?
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?
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? > > >
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? >> >> >> > >
"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.
"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..........
"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.
"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! 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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: zfeld |
last post by:
I am serializing an object to XML and writing it to disk. whenever a change
to my object occurs I call the save function to re-write to disk (see code
below). I am monitoring the directory where...
|
by: ljh |
last post by:
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?
|
by: =?Utf-8?B?S2xhdXMgR29sbGlu?= |
last post by:
Hi,
I am using FileSystemWatcher like this:
fsw = New IO.FileSystemWatcher(strPath, strFilename)
fsw.NotifyFilter = NotifyFilters.Size or NotifyFilters.LastWrite
fsw.EnableRaisingEvents =...
|
by: tomb |
last post by:
I'm using VB.net 2003 and a FileSystemWatcher. The Changed event gets
called twice for every change in the folder I'm watching. To build the
functionality, I'm manually changing a text file. As...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |