| commit | 76072a2dde4a4acc8be8d3c47efbc6811ebe0c1e | |
| author | Philip Withnall <withnall@endlessm.com> | |
| Fri, 10 Nov 2017 15:10:26 +0000 (10 15:10 +0000) | ||
| committer | Philip Withnall <withnall@endlessm.com> | |
| Tue, 28 Nov 2017 13:55:34 +0000 (28 13:55 +0000) | ||
| tree | 66eb0f3e294f849d629d043916131d87a3045eb7 | treesnapshot (tar.gz zip) |
| parent | 7d3e6738c5dcddad2ea89bcf475915b91a7ac42a | commitdiff |
kqueue: Fix invalid emission of G_FILE_MONITOR_EVENT_MOVED event
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
| gio/kqueue/kqueue-helper.c | diffblobblamehistory |