[tracker/miner-fs-refactor: 115/119] libtracker-miner: rephrase code comment
- From: Carlos Garnacho <carlosg src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [tracker/miner-fs-refactor: 115/119] libtracker-miner: rephrase code comment
- Date: Mon, 28 Nov 2011 13:06:05 +0000 (UTC)
commit 8fca1fe484a85576ac6a0c620de66e51e75fa2fe
Author: Carlos Garnacho <carlos lanedo com>
Date: Tue Nov 22 16:30:36 2011 +0100
libtracker-miner: rephrase code comment
It'd be indeed good to have tracker-miner-fs monitor directories
triggering a TRACKER_FILTER_PARENT_DIRECTORY filter in case that
situation changes (ie. the file triggering the filter disappears),
but given Tracker has never behaved like that and noone ever
complained, lower the comment severity a bit, it's not something
we should rush on.
src/libtracker-miner/tracker-file-notifier.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/src/libtracker-miner/tracker-file-notifier.c b/src/libtracker-miner/tracker-file-notifier.c
index b364ab8..ad7ebf0 100644
--- a/src/libtracker-miner/tracker-file-notifier.c
+++ b/src/libtracker-miner/tracker-file-notifier.c
@@ -796,9 +796,10 @@ monitor_item_deleted_cb (TrackerMonitor *monitor,
g_object_unref (parent);
g_list_free (children);
- /* FIXME: This supposedly works, but in practice
- * won't ever happen as the parent directory
- * wasn't being monitored if being ignored
+ /* note: This supposedly works, but in practice
+ * won't ever happen as we don't get monitor events
+ * from directories triggering a filter of type
+ * TRACKER_FILTER_PARENT_DIRECTORY.
*/
if (!indexable) {
/* New file was triggering a directory content
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]