"Walter Wang [MSFT]" <waw***@online.microsoft.com> wrote in message
news:5fGJLJH2GHA.2156@TK2MSFTNGXA01.phx.gbl...
> Hi Goran,
>
> I'm sorry that the documentation of FileSystemWatcher.InternalBufferSize
> didn't state very clear about the buffer size when monitoring network
> path.
> It's recommended not exceeds 64K when monitoring network path.
>
> FileSystemWatcher is basically a .Net wrapper for the Win32
> ReadDirectoryChangesW API.  To use ReadDirectoryChangesW, you create and
> specify a buffer that the OS will populate with the changes.  However,
> what
> is not mentioned in the ReadDirectoryChangesW documentation (but is hinted
> in the FileSystemWatcher 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 ReadDirectoryChangesW and is
> created in non-paged pooled memory.  Every time a FileSystemWatcher /
> ReadDirectoryChangesW 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 FileSystemWatcher / ReadDirectoryChangesW buffer.  This stems
> from
> the fact that there is a 64k limitation with network access as documented
> in ReadDirectoryChangesW.  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 ReadDirectoryChangesW 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, FileSystemWatcher and ReadDirectoryChangesW 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-us/fileio/base/change_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 (waw***@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>