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

[Lex Trotman]

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

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.

Cheers but Confused.
Lex

>
>>
>>  or it's a bug in my
>> > GLib version, I don't know.
>>
>> Which version??
>>
>
> Recent 2.26.0
>
>>  I changed the code of the callback to
>> > check mtime before setting doc->file_disk_status to CHANGE, and file
>> > saving is now works correctly for me.  If you think this change is
>> > meaningful, consider the patch I attach.  Apart of the change in the
>> > callback it contains some other staff (which you may wish to not
>> > commit).
>>
>> Well thats one way of telling the monitor that we know about the
>> changes because we caused them :-)
>>
>> Cheers
>> Lex
>>
>> >
>> > Best regards,
>> > Eugene.
>> > _______________________________________________
>> > Geany-devel mailing list
>> > Geany-devel at uvena.de
>> > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>> >
>> >
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>