Gio::FileMonitor::signal_changed()

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Gio::FileMonitor::signal_changed()

Phil Wolff-3
 From the Gio::FileMonitor::signal_changed() documentation:

"If using FILE_MONITOR_WATCH_MOVES on a directory monitor, and the
information is available (and if supported by the backend), event_type
may be FILE_MONITOR_EVENT_RENAMED, FILE_MONITOR_EVENT_MOVED_IN or
FILE_MONITOR_EVENT_MOVED_OUT."

I'm using Ubuntu 17.04 (glibmm-2.4 version 2.50.0) on an EXT4 file
system, and I obtain the FileMonitor using the FILE_MONITOR_WATCH_MOVES
flag. My callback receives all three of these event types, so presumably
the information *is* available and supported.

More from the docs:

"In all cases file will be a child of the monitored directory. For
renames, file will be the old name and other_file is the new name. For
'moved in' events, file is the name of the file that appeared and
other_file is the old name that it was moved from (in another
directory). For 'moved out' events, file is the name of the file that
used to be in this directory and other_file is the name of the file at
its new location."

My callback gets a non-null other_file *only* on a rename; other_file is
always null for either of the "moved" events. That's not the behavior
described above, but it does match what the docs say about the
deprecated Gio::FILE_MONITOR_SEND_MOVED flag (which I am *not* using):

"If using the deprecated flag FILE_MONITOR_SEND_MOVED flag and
event_type is FILE_MONITOR_EVENT_MOVED, file will be set to a File
containing the old path, and other_file will be set to a File containing
the new path.

"In all the other cases, other_file will be set to #nullptr."

There's obviously a problem here, but it's not clear to me where it lies.

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list