GNOME Bugzilla – Bug 547890
No move events for GFileMonitorEvent?
Last modified: 2010-02-18 14:52:56 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.
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!
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.
> 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
Any change to commit the patch to make gio works better?
"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).
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(-)