On Sun, 14 Nov 2010 22:02:31 +1100% Lex Trotman elextr@gmail.com wrote:
On 14 November 2010 21:37, Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 14 Nov 2010 21:24:39 +1100% Lex Trotman elextr@gmail.com wrote:
On 14 November 2010 20:31, Eugene Arshinov earshinov@gmail.com wrote:
Hi.
I don't know whether it was this change which caused this, but after I updated recently to r5395 and turned on the #define in document.c which controls using GIO file monitor, each time I save a document (I only use local filesystems) I get a dialog telling me the file was changed. In debug output coming from document.c:monitor_file_changed_cb() I see that CHANGE notification is sent twice after a file is saved. Maybe it's g_file_replace_contents() which cause this,
Possibly, g_file_replace_contents writes to the temp file and then renames the temp file to the old file, but why two??.
The interesting thing is why doesn't any change to the file trigger the monitor no matter how its written?? Why does it only happen for GIO IO??
I was not fully correct. There were 2 CHANGE notifications and 1 "unknown" notification between them. Here is the output I get after opening, changing and saving a file:
Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: IGNORE -> OK Geany-INFO: monitor_file_changed_cb: event: UNKNOWN; status: OK -> OK Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: OK -> OK
Since what is called change here is actually last_change_hint, you could actually get it several times because its only "probably" the last change.
Yes, and it also means that the original implementation, which ignores exactly one hint callback receives, is wrong. The comments near the #define actually tell that GIO based file monitoring is not completely stable, but when I ran an older version of Geany (maybe rev. 5380) with the #define turned on, saving seemed to work fine. Though there is a high probability that I'm wrong because I used that version only for testing new patches (i.e., rarely). Anyway, seems that I need to find a version where saving began to "fail".
The unknown could be move/rename delete or just plain change (probably *not* last??).
Note that with my patch the output is different from trunk, but things should be clear. I'll investigate the unknown notification a bit later today, maybe it is caused by the rename.
I'm not sure how g_file_monitor would report an atomic rename of a temp file over the file we are monitoring?? The directory entry is changed and the old inode and data deleted if this was the last hard link.
You would have to test it or look at the source.
Yes, there's a need for experiments.
But I still don't understand why using g_file_set_contents or plain fwrite doesn't trigger the monitor?? I can't see anywhere in document.c where it muzzles the monitor whilst saving.
Seems strange for me too.
Best regards, Eugene.