Re: Can g_file_monitor_file () report events from before it was created?
On Wed, 2011-09-07 at 03:18 +0100, Peter Clifton wrote: --=-RBhkyZn6RRXPH6Tyg7fR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2011-09-06 at 01:42 +0100, Peter Clifton wrote: --=3D-1PQvPQuhjpa09GLvybFI Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable =20 Hi, =20 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. =20 The order of operations is something like: =20 1. File monitor exists on the document file which was loaded last 2. User hits File-Save as.. (and enters a filename) ^__ Just as an interesting (and probably critical note), I don't see this bug if I hard-code a Save-as filename. I only get unexpected file-monitor events if I use a gtk_file_chooser_dialog to select the new filename to save into. Futhermore - it only breaks if the dialog is set to an initial location with something like: gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), *path); (Or left to pick the current working directory, where the file is). If I set the current folder to /, e.g.: gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), /); Then navigate to the directory I'm going to save into from within the GUI, the problem does not occur. -- 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
Re: Can g_file_monitor_file () report events from before it was created?
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.) Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can g_file_monitor_file () report events from before it was created?
On Tue, 2011-09-06 at 01:42 +0100, Peter Clifton wrote: --=-1PQvPQuhjpa09GLvybFI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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) ^__ Just as an interesting (and probably critical note), I don't see this bug if I hard-code a Save-as filename. I only get unexpected file-monitor events if I use a gtk_file_chooser_dialog to select the new filename to save into. I'm presuming that this dialog (or some IO plugin) may use g_file_monitor, or threads, or SOMETHING - which is causing issues with my own usage of g_file_monitor. If anyone could help shed some light on this, it would be much apprecaited. 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 monit= ored 5. Core of app notifies the GUI (with the file monitor) that the document w= e 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
Can g_file_monitor_file () report events from before it was created?
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
