Re: Can g_file_monitor_file () report events from before it was created?

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 06 Sep 2011 01:42:43 +0100
Peter Clifton <pcjc2 cam ac uk> wrote:
> I'm working on some code to monitor for file changes in our
> application, and ran into a bit of a problem today with the Save-As
> case.
>
> The order of operations is something like:
>
> 1. File monitor exists on the document file which was loaded last
> 2. User hits File->Save as.. (and enters a filename)
> 3. Core of app saves file into the new file name
> 4. File monitor does not fire, as the saved file is not the one being
> monitored 5. Core of app notifies the GUI (with the file monitor)
> that the document we should be watching is now in the new filename.
> 6. g_object_unref() the old file monitor 7. Create new file monitor
> on the new file.
>
> After this happens, I actually get a change event fire from the new
> file monitor - despite the changes having been saved by the app's core
> (fopen / fclose directly to the file in question), before I even
> created the file monitor.
>
> Is it possible that Glib / GIO is caching some state incorrectly, and
> spotting on-disk changes from _before_ I created the file monitor, or
> is it more likely that the file doesn't "hit the disk" until some time
> after I fclose() it - and that it spots the change at this point in
> time?

Does it help if you call fsync() on the underlying file descriptor
after calling fclose() (assuming you are using a unix-like OS)?  That
should at least force the write onto the hardware, so far as the kernel
is concerned.

From the man page of close(): "A  successful close does not guarantee
that the data has been successfully saved to disk, as the kernel defers
writes.  It is not common for a file system to flush the buffers when
the stream is closed.  If you need to be sure that the  data  is
physically stored use fsync(2).  (It will depend on the disk hardware
at this point.)"

Chris