0

I have a file in my filesystem that I need my program to read as frequently as possible. When the file changes, it will copy all the changes to a buffer and then empty the file.

This file is going to be written to occasionally by some other program.

The thing is, you can't both read from and write to one file at the same time. How do I make sure that my program checks the file as frequently as possible while still allowing other programs to write to it?

This program will not be multi-platform so I'd like to keep my code as dependent on the Windows API as possible to keep binary size down.

Thanks!

Christian Chapman
  • 1,018
  • 10
  • 27
  • Wow, after digging around this site some more it appears that it may be a near or exact duplicate of http://stackoverflow.com/questions/2317029/c-read-and-write-to-a-binary-file-at-the-same-time – Christian Chapman Jan 28 '12 at 02:42
  • 1
    Do you know beforehand which process will write to the file? Are you familiar with pipes? – Beta Jan 28 '12 at 02:43
  • No and not very. The thing writing to the file could be a text editor, it could be a disk copier, it could be anything. I've used Linux's pipe implementation some, is it similar to that of Windows? – Christian Chapman Jan 28 '12 at 02:47
  • 1
    I've worked with linux pipes; I hear that Windows pipes have similar behavior but very different command syntax. Basically a "named pipe" looks like a file and can be written to by any process as if it were a file, but it's actually connected to your program. – Beta Jan 28 '12 at 03:34
  • What you're looking for is called an "opportunistic lock". – Raymond Chen Jan 28 '12 at 09:12

2 Answers2

4

Try the FindFirstChangeNotification() API. It lets you know when a file is changed, among other things.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
0

The right approach would be to use a filter driver and not let the data get into the file, instead capturing them on the fly and using them. A trivial task if you have a filesystem filter driver (we do ;). All other approaches are prone to either skipping data or reacting too slow or causing sharing violations (depending on what application writes the data to the file).

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Isn't a filesystem driver overkill when the change notification API exists for exactly this purpose? – Andrew Lambert Jan 28 '12 at 08:15
  • @Amazed notification API is based on different principles. Basically, it's a reading of the filesystem change log. Consequently it's severely limited in functionality. With filesystem filter driver you can modify the data or deny the operation altogether, as filtering is synchronous. Also with the filter you don't miss the change, as it's easy to do with notification API. – Eugene Mayevski 'Callback Jan 28 '12 at 08:20
  • How is it possible for the notification API to 'miss' a change when, as you say, it's reading the change log? It's not as though the change log on a journaling filesystem is an unreliable source of information. Of course this is assuming that the USN journal is used for the notification API; the docs don't mention how changes are detected, just what kind of changes. For all we know change notification callbacks may be invoked directly by the built-in filesystem drivers, or by some other subsytem in the kernel. – Andrew Lambert Jan 28 '12 at 18:02
  • @Amazed official docs say that they can be missed as the log is limited in size. Now, SO is question-answer site, not a discussion board. If you want to *discuss* something, use http://chat.stackoverflow.com/ – Eugene Mayevski 'Callback Jan 29 '12 at 09:47