12/16/2023 0 Comments Windows server 2008 filewatcherThis may sound really bad, but since the scan is event-driven, it's still much more efficient than dumb polling. On receiving a notification, always do a full directory scan. If the files you're looking for have sequence numbers, store the last sequence number you got notified about, so you can look for 'gaps' on future notifications and process the files for which you didn't get notified When using file system watchers, your application should be able to deal with these limitations. Another question here on SO details the inherent reliability problems with the API in a bit more detail. This is even an issue with local file system watchers, but it's much more of a problem over the network. In other words: under high load (when you would need a large buffer) or, worse, under random unspecified circumstances, you may not get the notifications you expect. Notifications may not be returned when calling FindFirstChangeNotification for a remote file system This is due to a packet size limitation with the underlying file sharing protocols ReadDirector圜hangesW fails with ERROR_INVALID_PARAMETER when the buffer length is greater than 64 KB and the application is monitoring a directory over the network. From the MSDN documentation for the Win32 API functions: Other than having to deal with network connections going away temporarily (which isn't too much of a problem, since IO.FileSystemWatcher will fire an error event in this case which you can handle), the underlying mechanism has certain fundamental limitations. The only problem with this solution is that it's not very reliable. NET wrapper also uses async I/O and everything, further assuring maximum efficiency. It uses the FindFirstChangeNotification and ReadDirector圜hangesW Win32 API functions internally, which in turn communicate with the network redirector in an optimized way (assuming standard Windows networking: if a third-party redirector is used, and it doesn't support the required functionality, things won't work at all). I suppose the other solution is a periodic check if the FSW creates an undue load on the server, or if it doesn't work for a whole bunch of SysAdmin type reasons.įrom a server load point of view, using the IO.FileSystemWatcher for remote change notifications in the scenario you describe is probably the most efficient method possible. I may not always have this option hence the team of watchers. How about 10 separate watchers to cut down the number of folders/files being watched? (down to 200 from 700 folders, 1200 from 5500 files in total) More network traffic instead of less? My thoughts are a reshuffle on the server to put the watched files under 1 tree. NET System.IO.fileSystemWatcher create much of a load on the server? I am watching for Create, Delete, Rename and Changes. I can live with a minute or more delay in notifications. Timeliness is not particularly important. I can't write a service to run on the server (off-limits!) so the solution has to be local to the client. There are about 200 folders in the tree and about 1200 files with the extension I am watching. I want to watch a folder tree on a network server for changes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |