Hi, 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? Any ideas what I might be doing wrong here? (PS. I got the feeling GLib / GIO is using polling, not anything clever like inotify to spot changes - is this correct?) Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
