This has broken gnome-software update notifications. The following no longer works and the "changed" signal doesn't get emitted:

        offline_update_file = g_file_new_for_path ("/var/lib/PackageKit/prepared-update");
        offline_update_monitor = g_file_monitor_file (offline_update_file, 0, NULL, NULL);
        g_signal_connect (offline_update_monitor, "changed",
                          G_CALLBACK (offline_update_monitor_cb), monitor);


touch /var/lib/PackageKit/prepared-update.tmp
mv /var/lib/PackageKit/prepared-update.tmp /var/lib/PackageKit/prepared-update

At this point, with glib 2.44 we used to get the "changed" signal. With glib master, nothing happens.

Any other operations ('touch' the file, remove, rename to something else) work fine; it's just the renaming of a temp file to the watched file that doesn't.

*** Bug 752432 has been marked as a duplicate of this bug. ***

Also affects gnome-online-accounts: https://bugzilla.gnome.org/show_bug.cgi?id=752432#c8

This bug has been proposed as a blocker for the Fedora 23 release.

Test case available here: https://bugzilla.redhat.com/show_bug.cgi?id=1225957

This is remarkably bad.  Looking into it now.

Hi glib developers,

And I experienced the 'same' issue when deleted user by AccountsService https://bugs.freedesktop.org/show_bug.cgi?id=91612

the file monitors setup for /etc/passwd,  /etc/shadow, /etc/group might fail to queue_reload_users_soon.

Please give me some advice, thanks a lot!

Regards,
Leslie Zhai

*** Bug 753602 has been marked as a duplicate of this bug. ***

I think bug 753602 is on the right track.

If I remove the check for wd being different for paired events, I do see events for atomic replace again.

With G_FILE_MONITOR_WATCH_MOVES, I get a RENAMED event with file being the monitored file and other_file being the temp file that is moved in its place.

Without G_FILE_MONITOR_WATCH_MOVES, I get a DELETED event for the monitored file and a CREATED event for the temp file that is moved in its place, which seems backwards.

Here is a patch that seems to make things work as expected for me. It makes sure we deliver the first half of an event pair if either end of the pair has the right filename.


diff --git a/gio/inotify/inotify-path.c b/gio/inotify/inotify-path.c
index c27ed4a..ec1d486 100644
--- a/gio/inotify/inotify-path.c
+++ b/gio/inotify/inotify-path.c
@@ -463,7 +463,8 @@ ip_event_dispatch (GList      *dir_list,
           */
          if (sub->filename &&
              event->name &&
-             strcmp (sub->filename, event->name))
+             strcmp (sub->filename, event->name) &&
+              (!event->pair || !event->pair->name || strcmp (sub->filename, event->pair->name)))
            continue;
          
          /* If the subscription has a filename

Hi Matthias,

I tested with your patch, but Accounts Service still show the deleted 'zombie' user.

Regards,
Leslie Zhai

This is my understanding of it, take it with a grain of salt.

Each file that is monitored get a unique wd. So a IN_MOVED_TO event and a IN_MOVED_FROM event concerning the same file will always have the same wd.

That is why I proposed the patch in bug 753602 that removed the check that the paired event can not have the same wd. I can not see how paired events from the same file could ever work with that check in place. Since the paired events are generated from the same file and therefore they also have the same wd.

Martin:

Only the IN_MOVED_FROM event gets put in the queue for such pairs. It matches INOTIFY_DIR_MASK and thus gets dispatched in inotify-path.c:547. Unfortunately, it then gets filtered out by the check in inotify-path.c:464 since the 'from' event has the wrong filename, and the 'to' event is what matches. That is what my patch corrects.

And, btw, the events are not from the same file, but for two different files in the same directory. The watch is on the directory.

(In reply to Matthias Clasen from comment #13)
> Martin:
> 
> Only the IN_MOVED_FROM event gets put in the queue for such pairs. It
> matches INOTIFY_DIR_MASK and thus gets dispatched in inotify-path.c:547.
> Unfortunately, it then gets filtered out by the check in inotify-path.c:464
> since the 'from' event has the wrong filename, and the 'to' event is what
> matches. That is what my patch corrects.

Ok, that makes sense. I also found out why your patch didnt work for bug 753602. There is another 'from' and 'to' filename check in glocalfilemonitor.c that filters out the rename event. The following patch toghether with your patch fixes bug 753602 for me.

diff --git a/gio/glocalfilemonitor.c b/gio/glocalfilemonitor.c
index dcd39cf..61c19e1 100644
--- a/gio/glocalfilemonitor.c
+++ b/gio/glocalfilemonitor.c
@@ -344,7 +344,9 @@ g_file_monitor_source_handle_event (GFileMonitorSource *fms,
   g_assert (!child || is_basename (child));
   g_assert (!rename_to || is_basename (rename_to));
 
-  if (fms->basename && (!child || !g_str_equal (child, fms->basename)))
+  if (fms->basename &&
+     (!child || !g_str_equal (child, fms->basename)) &&
+     (!rename_to || !g_str_equal (rename_to, fms->basename)))
     return TRUE;
 
   g_mutex_lock (&fms->lock);

yeah, I found the same, that hunk was missing from my patch