On Sun, 14 Nov 2010 19:29:08 +0300% Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 14 Nov 2010 14:25:54 +0300% Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 14 Nov 2010 22:02:31 +1100% Lex Trotman elextr@gmail.com wrote:
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…
Okay, [1] is the function of GLib 2.26.0 which is finally called in my case to open a stream for writing. In this particular case the original file is opened, but the fd is never used: instead a temporary file is opened and its fd is returned, and the original fd is just closed, hence the first meaningless change hint.
By the way, the function hasn't changed in GLib's "trunk" since 2.26.0.
[1] http://nopaste.geany.org/p/mefaf389
Best regards, Eugene.