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

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 6 Sep 2011 11:40:59 +0100
Chris Vine <chris cvine freeserve co uk> wrote:

> 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.)"

Actually, that should be "Does it help if you call fsync() on the
underlying file descriptor after calling fflush() and before calling
fclose()" (presumably fclose() will at some point call close() which
will invalidate the descriptor).

Chris