0

Say I want to write a tail like application for Windows to monitor a bunch of files. Such an application should report when some of the monitored files is updated by any other application.

It can be assumed that the files being monitored are being constantly appended by other processes, but not modified in any other way. Before implementing some pooling solution (that is, iterate through the files to be monitored, seek to the end of each one, record this pointer, compare to previous end etc.) I would appreciate if someone more experienced with the Overlapped IO could tell me if I can make use of it.

For instance, is it possible to write the monitoring application in such a way that it opens all the files that need to be monitored, seek to the end of them, and try to read one byte with ReadFileEx() registering a callback.

Is there a way to make this work so that when another process write to some of the files the proper callback is invoked? Or necessarily the monitoring application will always get an EOF for such a call?

Is this approach a sensible one? Or is it a bad idea?

Tarc
  • 3,214
  • 3
  • 29
  • 41
  • *files are being constantly appended by other processes*, *I open all the files* - about which files you speak ? i be say absolute unclear about what you asking at all – RbMm Jan 02 '18 at 14:12
  • Ok, I'll try to improve. – Tarc Jan 02 '18 at 14:13
  • 1
    you can use `ReadDirectoryChangesW` for get notify when files in some folder changed. *Is there a way to make this work so that when another process write to some of the files the proper callback is invoked?* - apc callback - no - it called in context of calling thread. iocp callback ? but for this you need register your callback with this file handle, nobody else register it and nobody use apc callbacks. and parameters you also not control for callback. - so also no – RbMm Jan 02 '18 at 14:27
  • 2
    The overlapped I/O will immediate complete with "end of file reached". – Raymond Chen Jan 02 '18 at 14:27
  • I think the name I was looking for was IOCP, but as you say it cannot be used the way I was thinking. I'll look into `ReadDirectoryChangesW()` though. Thank you both for your comments. – Tarc Jan 02 '18 at 14:42
  • 1
    @Tarc - *IOCP* is bind to concrete `FILE_OBJECT` (from user view can say for concrete handle) only. when some io operation complete on this *concrete* file handle will be packet queued to *iocp*. in your concrete case this is absolute not usefull – RbMm Jan 02 '18 at 14:46
  • and anyway unclear final target. say you got notify, via `ReadDirectoryChangesW` that some file was changed - and so what ? what you will try do with this ? – RbMm Jan 02 '18 at 14:51
  • @RbMm I could initially populate a map with the size of the files to be monitored and every time I'm notified with `ReadDirectoryChangesW()`, check if the file is one I'm interested in and read the size again. If the sizes don't match, an append must have happened. – Tarc Jan 02 '18 at 14:56
  • you want append some data to file after another process append some data to it ? but this will be not synchronized with another process. what if he append "partial" data only say ? if it begin append new data in concurent with you ? what sense in this ? – RbMm Jan 02 '18 at 15:04
  • @RbMm Maybe I didn't express myself correctly. The monitoring application I'm talking would not append data to the files it monitors, just try to sense when some of them is being appended by other applications. – Tarc Jan 02 '18 at 15:06
  • 2
    are the files you're trying to monitor continuously being opened and written too? use procmon to see the file access pattern, see if taking an oplock can help. FSCTL_REQUEST_OPLOCK with cache_read, if it breaks then you know someone is trying to modify. – amritanshu Jan 03 '18 at 13:13

0 Answers0