Hi Goran,
I'm sorry that the documentation of FileSystemWatch er.InternalBuff erSize
didn't state very clear about the buffer size when monitoring network path.
It's recommended not exceeds 64K when monitoring network path.
FileSystemWatch er is basically a .Net wrapper for the Win32
ReadDirectoryCh angesW API. To use ReadDirectoryCh angesW, you create and
specify a buffer that the OS will populate with the changes. However, what
is not mentioned in the ReadDirectoryCh angesW documentation (but is hinted
in the FileSystemWatch er docs) is that the file system creates an internal
kernel buffer to store the change information temporarily until it has the
chance to update the user buffer. The size of the kernel buffer that is
created is the same size that is specified in ReadDirectoryCh angesW and is
created in non-paged pooled memory. Every time a FileSystemWatch er /
ReadDirectoryCh angesW is created / called, a new kernel buffer is also
created.
The kernel memory pools (paged and non-paged) are set aside in the system
address space for device drivers and other kernel components to use. They
grow and shrink dynamically as necessary. The current size of the pools
can be easily seen by going to the Performance tab of the Task Manager.
The pools will grow dynamically until they hit a maximum value which is
calculated at boot time and depends on available system resources (mostly
RAM). You do not want to hit this maximum value or else various system
services and drivers will start failing. However, this calculated maximum
value is not easily available. To determine the maximum pool sizes, you
need to use a kernel debugger. If you are interested in further
information about the system memory pools, I recommend that you look at
Chapter 7 in the MSPress book Inside Windows 2000 by Solomon and
Russinovich.
With this in mind, there is no recommendation on what size buffers you can
use. The current and maximum size of the system pools are going to be
varied from client to client. However, you probably should not go over 64k
for each FileSystemWatch er / ReadDirectoryCh angesW buffer. This stems from
the fact that there is a 64k limitation with network access as documented
in ReadDirectoryCh angesW. But in the end you are going to have to test the
application on a variety of expected target systems so that you can tune
your buffer.
There is overhead associated with .Net applications and I imagine that a
Win32 ReadDirectoryCh angesW program might be able to achieve better
performance with the same buffer size. However, with very fast and
numerous file changes, buffer overruns will be inevitable and the developer
is going to have to handle the case when an overrun occurs such as manually
enumerating the directory to detect the changes.
In conclusion, FileSystemWatch er and ReadDirectoryCh angesW are a
lightweight file change detection mechanism that is going to have its
limitations. Change Journals is another mechanism which we would consider
a medium-weight solution, but would still have limitations:
http://msdn.microsoft.com/library/en...e_journals.asp
Heavy-weight solutions would be to write a dedicated file system filter
driver that sits in the file system stack and monitors file system changes.
Of course this would be the most complex approach. Most virus scanners,
backup software, and file system monitoring utilities such as filemon
(
www.sysinternals.com) implement a filter driver.
I hope above explanation helps you to understand the root cause of the
issue you're experiencing. Please reply to let us know whether or not you
need further information. Thank you.
Sincerely,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.
