Re: Can g_file_monitor_file () report events from before it was created?
- From: Chris Vine <chris cvine freeserve co uk>
- To: Chris Vine <chris cvine freeserve co uk>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Can g_file_monitor_file () report events from before it was created?
- Date: Tue, 6 Sep 2011 11:46:38 +0100
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
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).
] [Thread Prev