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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]