[Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO

[Eugene Arshinov]

Some results after preliminary investigation:

On Sun, 14 Nov 2010 14:25:54 +0300%
Eugene Arshinov <earshinov at gmail.com> wrote:

> On Sun, 14 Nov 2010 22:02:31 +1100%
> Lex Trotman <elextr at gmail.com> wrote:
> 
> > On 14 November 2010 21:37, Eugene Arshinov <earshinov at gmail.com>
> > wrote:
> > > On Sun, 14 Nov 2010 21:24:39 +1100%
> > > Lex Trotman <elextr at gmail.com> wrote:
> > >
> > >> On 14 November 2010 20:31, Eugene Arshinov <earshinov at 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".

Okay, it still fails at r5380.  The change is caused by
g_file_replace_contents() which was introduced before than that.
 
> 
> > 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.
> 

r5395
  Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2
  Geany-Message: monitor_file_changed_cb: FILE_CHANGED
  Geany-INFO: monitor_file_changed_cb: event: 3 previous file status: 0
  Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 0
  Geany-Message: monitor_file_changed_cb: FILE_CHANGED

r5065 (before g_file_replace_contents())
  Geany-INFO: monitor_file_changed_cb: event: 0 previous file status: 2
  Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2
  Geany-Message: monitor_file_changed_cb: FILE_CHANGED

Events:
  0 - CHANGED
  1 - CHANGES_HINT (handled in Geany)
  3 - CREATED

It's natural that CREATED is reported, but it's still unclear why
the first CHANGES_HINT is sent.  Going to investigate further…

> > 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.

Actually g_file_replace_contents(), g_file_set_contents(), and fwrite()
- are called in document.c:write_data_to_disk()
- which is only called in document.c:save_doc()
- which is only called in document_save_file()
- which itself sets file_disk_status to FILE_IGNORE.

So we ignore the first change hint despite of the function that is
finally called.

> 
> Best regards,
> Eugene.