On Tue, 6 Sep 2011 11:40:59 +0100 Chris Vine <ch...@cvine.freeserve.co.uk> wrote:
> On Tue, 06 Sep 2011 01:42:43 +0100 > Peter Clifton <pc...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
