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 547890 - No move events for GFileMonitorEvent?
No move events for GFileMonitorEvent?
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Martyn Russell
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-08-15 09:54 UTC by Martyn Russell
Modified: 2010-02-18 14:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to support the "other-file" parameter in the signal emission (2.23 KB, patch)
2008-08-19 14:51 UTC, Martyn Russell
none Details | Review

Description Martyn Russell 2008-08-15 09:54:47 UTC
I was just looking into how to know if a file or directory has moved using the GIO API GFileMonitor and didn't see any MOVE events there:

  http://library.gnome.org/devel/gio/stable/GFileMonitor.html

So I thought, ok, perhaps the "other_file" parameter is used in CREATE or DELETE events when g_file_monitor_emit_event() is called. I checked the source, it is NULL in every single call.

Inotify has MOVE_TO, MOVE_FROM, MOVE_SELF events. So it would be really easy to use that information and make this API much more affluent. I am not so sure about FAM and others, I suspect a lot of extra code would be needed to do that sort of thing. So I understand why there are no event types for MOVE, but really, why aren't we using the inotify events to at least pass "other_file" so we know it is a move event of some type. Or Maybe add a MOVE event and just document that it isn't available for all backends. This is certainly already the case for FAM and which never emits G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT because it can't really know easily.

Would a patch to fix this be accepted? 
Primarily I am concerned with the inotify backend.
Comment 1 Martyn Russell 2008-08-19 14:51:50 UTC
Created attachment 116968 [details] [review]
Patch to support the "other-file" parameter in the signal emission

This patch simply uses the event->pair information which is basically the OTHER event information we have when we emit events. 

The patch doesn't break API by adding a new event type, it simply makes use of the current API more effectively. At least with this patch users will be able to know on a DELETE event that the other file is the new CREATE event that is about to follow and can use some simple logic to know about MOVE events.

The documentation for the "other-file" variable in Glib for this is non-existant as far as I recall. If this approach is accepted I will write the documentation in a follow up patch.

Comments welcome!
Comment 2 Alexander Larsson 2008-09-23 08:06:47 UTC
The plan was always to eventually add a move event, which use the "other" argument.

Of course, that changes the behaviour, so we would need a flag to enable generation of move events.
Comment 3 Philip Van Hoof 2009-12-31 10:54:17 UTC
> year old :-\

We'd like to switch back from using our own libinotify code to nicely abstracted GIO, so that the nice people at Sun can also use tracker-miner-fs. It might also make our own transition to using famnotify over libinotify more easy, eventually.

What is the ETA for a review of this patch?

http://mail.gnome.org/archives/tracker-list/2009-December/msg00104.html
Comment 4 jerry tan 2010-01-04 02:29:59 UTC
Any change to commit the patch to make gio works better?
Comment 5 Alexander Larsson 2010-01-14 09:27:53 UTC
"What is the ETA for a review of this patch?"

The review is in comment #2, but I'll repeat it here:

Yes, we would like to support (optional) move events, but we don't want paired delete+create events, but a new MOVE event. So, the patch need to be extended to add a MOVE event and a new flag in GFileMonitorFlags to enable MOVE events (documented to only work on some backends).
Comment 6 Christian Kellner 2010-02-18 14:52:56 UTC
Fixed on git master (a5dc1af..48f74ca). Thanks martyn and alex.

 gioenums.h                         |   12 +++++++--
 glocalfilemonitor.c                |   28 ++++++++++++++++++---
 glocalfilemonitor.h                |    1 
 inotify/ginotifydirectorymonitor.c |    7 +++--
 inotify/ginotifyfilemonitor.c      |    9 ++++++
 inotify/inotify-helper.c           |   49 ++++++++++++++++++++++++++++++++-----
 inotify/inotify-kernel.c           |    4 +--
 inotify/inotify-path.c             |   18 +++++++++++++
 inotify/inotify-path.h             |    8 +++---
 inotify/inotify-sub.c              |    6 +++-
 inotify/inotify-sub.h              |    3 +-
 11 files changed, 122 insertions(+), 23 deletions(-)