BradKilmer
asked on
Need to monitor file activity (without scanning with FindFirst)
I need to monitor and log file activity in a directory tree for a timesheets program. My old version simply scanned the entire tree and logged the file info that had changed (either created or modified). However, this is becoming unworkable due to the ever expanding tree. Is there a way to link into some notification mechanism so that my app could stop the periodic (and now time-consuming) scans. I'd like to have it behave like the Windows Explorer which somehow knows that a new file has been added to a folder and uses that notification to update its file list.
http://delphi.about.com/od/kbwinshell/l/aa030403a.htm
ASKER
Oops. I take it back. That's not what I'm looking to do. I downloaded and installed the TSHChangeNotify component and did a few file operations within Windows Explorer and they were logged as expected. I thought that was the answer; however, I was wanting to receive notifications whenever ANY application modified files within a specified tree. I want to log the name all files being created/deleted/modified by any app; the only event logged by this component when a non-shell file operation is performed is the UpdateDir (and that's only when you have the Windows Explorer opened to the folder where the affected files reside, and I've already observed 2 failures to log even that).
Still looking...
Still looking...
ASKER
That's closer. The events are fired when the specified changes occur (from any app), but I need to get the file names that trigger the change events; I can't see where the filename information is accessible at any point during the event processing. Therefore, I would still have to scan the directory tree being monitored to see what change triggered the event: scanning the directory tree brings me back to square one (that's what I'm trying to get away from). Thanks for your help, but I'm thinking that my best option is to optimize my existing code so that scans the directory tree in short bursts and stops locking up the main VCL thread for tens of seconds at a time; it doesn't have to scan that rapidly, just constantly.
Thanks
BK
Thanks
BK
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
PERFECT!
Thanks!
BK
Thanks!
BK