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

FileSystemWatcher across the network

P: n/a
Hi all,
I have a file system watcher service that works fine on a local hard drive, but will not work across the network. I tried both: mapping the drive and "\\..." path both no luck. I don't receive any errors, it is just that FileSystemWatcher doesn't see any files dropped in the folder. What could be wrong?

Thanks
Goran
Sep 14 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Some basic troubleshooting steps:

1. Make sure the FileSystemWatcher's EnableRaisingEvents property is set to true.
2. Make sure you have not set the FileSystemWatcher's Filter to ignore the type of files being dropped into the folder.
3. Make sure you have set the FileSystemWatcher's NotifyFilter to include to watch for Created files.
--
Mike

Mike McIntyre [MVP]
http://www.getdotnetcode.com
"Goran Djuranovic" <go**************@newsgroups.nospamwrote in message news:uA**************@TK2MSFTNGP03.phx.gbl...
Hi all,
I have a file system watcher service that works fine on a local hard drive, but will not work across the network. I tried both: mapping the drive and "\\..." path both no luck. I don't receive any errors, it is just that FileSystemWatcher doesn't see any files dropped in the folder. What could be wrong?

Thanks
Goran
Sep 14 '06 #2

P: n/a
Hi Mike,
Thanks for your response. Yes, all of those are set correctly.
Using this works fine:
With Me.FolderWatcherObj
.NotifyFilter = (NotifyFilters.FileName Or NotifyFilters.LastWrite Or NotifyFilters.LastAccess Or NotifyFilters.CreationTime Or NotifyFilters.Size)
.Path = "C:\MyFolder"
.Filter = "*.txt"
.IncludeSubdirectories = False
.InternalBufferSize = .InternalBufferSize + 81920
.EnableRaisingEvents = True
End With

Using this doesn't work:
With Me.FolderWatcherObj
.NotifyFilter = (NotifyFilters.FileName Or NotifyFilters.LastWrite Or NotifyFilters.LastAccess Or NotifyFilters.CreationTime Or NotifyFilters.Size)
.Path = \\MyServer\MyFolder <---------- NOTE THE CHANGE
.Filter = "*.txt"
.IncludeSubdirectories = False
.InternalBufferSize = .InternalBufferSize + 81920
.EnableRaisingEvents = True
End With

Goran

"Mike McIntyre" <mi****@getdotnetcode.comwrote in message news:Oc**************@TK2MSFTNGP02.phx.gbl...
Some basic troubleshooting steps:

1. Make sure the FileSystemWatcher's EnableRaisingEvents property is set to true.
2. Make sure you have not set the FileSystemWatcher's Filter to ignore the type of files being dropped into the folder.
3. Make sure you have set the FileSystemWatcher's NotifyFilter to include to watch for Created files.
--
Mike

Mike McIntyre [MVP]
http://www.getdotnetcode.com
"Goran Djuranovic" <go**************@newsgroups.nospamwrote in message news:uA**************@TK2MSFTNGP03.phx.gbl...
Hi all,
I have a file system watcher service that works fine on a local hard drive, but will not work across the network. I tried both: mapping the drive and "\\..." path both no luck. I don't receive any errors, it is just that FileSystemWatcher doesn't see any files dropped in the folder. What could be wrong?

Thanks
Goran
Sep 14 '06 #3

P: n/a
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...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.

Sep 15 '06 #4

P: n/a
What Server OS is the target filesystem on? As far as I know, only Win95,
98, ME, XP, 2000, and 2003 support the FSW interface. NT 4 and earlier and
no version of Samba that I'm aware of support FSW.

Mike Ober.

"Goran Djuranovic" <go**************@newsgroups.nospamwrote in message
news:uA**************@TK2MSFTNGP03.phx.gbl...
Hi all,
I have a file system watcher service that works fine on a local hard drive,
but will not work across the network. I tried both: mapping the drive and
"\\..." path both no luck. I don't receive any errors, it is just that
FileSystemWatcher doesn't see any files dropped in the folder. What could be
wrong?

Thanks
Goran

Sep 15 '06 #5

P: n/a
Walter,
You were right on the target. Nothing else was wrong, but the
InternalBufferSize. When I decreased it to 50K (51200B) worked like a charm.
It would not work above that size for that specific network connection.

Thanks a lot everyone
Goran Djuranovic
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:5f**************@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...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.

Sep 15 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.