After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751358 - GFileMonitor doesn't react to "mv some-file watched-file"
GFileMonitor doesn't react to "mv some-file watched-file"
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
2.45.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 752432 753602 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-06-23 07:12 UTC by Marius Vollmer
Modified: 2015-08-19 18:58 UTC
See Also:
GNOME target: 3.18
GNOME version: ---



Description Marius Vollmer 2015-06-23 07:12:32 UTC
Trying to get more exposure for this:

    https://bugzilla.redhat.com/show_bug.cgi?id=1225957
Comment 1 Kalev Lember 2015-08-01 14:34:43 UTC
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.
Comment 2 Debarshi Ray 2015-08-05 14:49:32 UTC
*** Bug 752432 has been marked as a duplicate of this bug. ***
Comment 3 Debarshi Ray 2015-08-05 14:50:19 UTC
Also affects gnome-online-accounts: https://bugzilla.gnome.org/show_bug.cgi?id=752432#c8
Comment 4 Stef Walter 2015-08-06 10:10:29 UTC
This bug has been proposed as a blocker for the Fedora 23 release.
Comment 5 Stef Walter 2015-08-10 11:09:14 UTC
Test case available here: https://bugzilla.redhat.com/show_bug.cgi?id=1225957
Comment 6 desrt's bugzilla bot 2015-08-12 09:28:45 UTC
This is remarkably bad.  Looking into it now.
Comment 7 Leslie Zhai 2015-08-13 01:21:17 UTC
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
Comment 8 Matthias Clasen 2015-08-19 05:01:23 UTC
*** Bug 753602 has been marked as a duplicate of this bug. ***
Comment 9 Matthias Clasen 2015-08-19 05:05:42 UTC
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.
Comment 10 Matthias Clasen 2015-08-19 05:14:50 UTC
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
Comment 11 Leslie Zhai 2015-08-19 06:22:56 UTC
Hi Matthias,

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

Regards,
Leslie Zhai
Comment 12 Martin Andersson 2015-08-19 09:07:31 UTC
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.
Comment 13 Matthias Clasen 2015-08-19 11:01:33 UTC
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.
Comment 14 Matthias Clasen 2015-08-19 11:02:48 UTC
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.
Comment 15 Martin Andersson 2015-08-19 14:34:50 UTC
(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);
Comment 16 Matthias Clasen 2015-08-19 17:13:51 UTC
yeah, I found the same, that hunk was missing from my patch