On 2/14/2013 7:18 AM, Mike Ho wrote:
Just a quick note, FileSystemWatcher in .NET is actually not recommended for
use by Microsoft.
It does not guarantee that an event will be raised on every new file or file
mod in a given folder… and it's even less determinstic when trying to deal with
network share drives.
Microsoft's own developer blogs usually recommend that people roll their own
polling-based solution instead of depending on FileSystemWatcher (googling
FileSystemWatcher will yield many many results regarding this).
I'm not necessarily saying that the overall idea is without merit… but it's
just that if someone does want to try and implement something like this on
Windows, they should try and avoid whatever Win32 API calls that
FileSystemWatcher uses.
--Mike
For Windows, I've got notes that there is a Windows API for accessing
the NTFS journal (DeviceIoControl() with FSCTL_QUERY_USN_JOURNAL). IMO
as the author of a change monitoring tool, that API would be the most
reliable user-mode access point for watching for the majority of file
system changes:
http://msdn.microsoft.com/en-us/library/aa365736%28VS.85%29.aspx
It requires system or Administrator privileges to read NTFS journal
records. Of course, if you are going to go as far as needing admin
rights, it might simply be better to write a Windows driver and hook the
file system calls as some SysInternals tools do and get reliable
results. With the user-mode Windows API, you still run the risk of
missing entries with NTFS if there are a bunch of updates back to back.
It still qualifies as polling, but it is faster polling than scanning
a large number of files and directories. It also only works with NTFS,
so other mounted file systems won't work.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you might find useful.
http://cubiclesoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
