1. 04 Mar, 2019 3 commits
    • Carlos Garnacho's avatar
      libtracker-miner: Dispose cached events on MONITOR_EVENT_DELETED · 66fc15e9
      Carlos Garnacho authored
      I don't know if this is possible, but in case that happens we should
      drop the event either way, and neutralize CREATED+DELETED events early
      on.
      66fc15e9
    • Carlos Garnacho's avatar
      libtracker-miner: Preserve first cached event · f12117df
      Carlos Garnacho authored
      We cache both CREATED and CHANGED events here, if we get both while
      waiting for the CHANGES_DONE_HINT, it makes things more consistent
      to cache the first CREATED event.
      
      This did not result in bugs as the miner reacts the same either way.
      f12117df
    • Carlos Garnacho's avatar
      libtracker-miner: Fix thinko in condition · 8b882ccf
      Carlos Garnacho authored
      use_changed_event refers to FAM and the inability of the GIO monitor
      implementation to send CHANGES_DONE_HINT for it. This means we have
      to forward CREATED/CHANGED events immediately if we have to rely on
      FAM-backed monitors.
      
      However the condition handling this was inverted, which meant we
      sucked with file monitors that honored CHANGES_DONE_HINT, and
      completely broke updates on FAM monitors.
      
      Closes: tracker-miners#36
      8b882ccf
  2. 02 Mar, 2019 2 commits
  3. 13 Feb, 2019 1 commit
  4. 24 Jan, 2019 2 commits
    • Andrea Azzarone's avatar
      tracker-monitor: Prevent stack smashing · f36b07fd
      Andrea Azzarone authored
      Make sure to use GPOINTER_TO_UINT when using g_hash_table_lookup_extended() to
      prevent stack smashing. This will make sure that in the architectures where
      sizeof(GFileMonitorEvent) < sizeof(gpointer), g_hash_table_lookup_extended()
      will not write more bytes than prev_event_type can hold.
      
      Fixes: #71
      f36b07fd
    • Andrea Azzarone's avatar
      tracker-monitor: Prevent stack smashing · 63c0a5d4
      Andrea Azzarone authored
      Make sure to use GPOINTER_TO_UINT when using g_hash_table_lookup_extended() to
      prevent stack smashing. This will make sure that in the architectures where
      sizeof(GFileMonitorEvent) < sizeof(gpointer), g_hash_table_lookup_extended()
      will not write more bytes than prev_event_type can hold.
      
      Fixes: #71
      63c0a5d4
  5. 12 Nov, 2018 1 commit
  6. 12 Oct, 2018 1 commit
  7. 16 Jan, 2018 1 commit
  8. 14 Nov, 2017 6 commits
    • Carlos Garnacho's avatar
      libtracker-miner: Clean up TrackerMonitor · 3bc295d2
      Carlos Garnacho authored
      We used to implement our own caching and timeout mechanism on top
      of GIO's, and our own "blacklisting" that would merge or transform
      events depending on the previouly cached content.
      
      This adds quite some extra latency in some cases on top of
      GFileMonitor's rate (up to 2s), and even in some cases do produce
      mistaken results (CREATE(a)+MOVE(a->b) != CREATE(b) if you are rewriting
      a file, but how can TrackerMonitor know).
      
      The code has been simplified in various fronts:
      - (Almost) no event caching. Only CREATED/UPDATED events are possibly
        cached awaiting for the CHANGES_DONE_HINT that must follow them.
      - No event manipulation nor merging. GFileMonitor does a good job at
        being truthful, and the upper layers do know better how to coalesce
        events into a more reduced set of equivalent tasks, since there's
        further info like file state in the database.
      - The deprecated SEND_MOVED flag has been replaced by WATCH_MOVES. The
        MOVED_IN/MOVED_OUT/RENAMED events can be handled in a simpler way each
        than the deprecated MOVED event.
      
      Overall this makes TrackerMonitor slightly more verbose (but still
      consistent wrt sending a meaninful sequential set of changes), but more
      reactive overall, since we now solely rely on GFileMonitor rate limits.
      
      With this change, TrackerMinerFS is left as the only place that does
      coalescing of events.
      3bc295d2
    • Carlos Garnacho's avatar
      libtracker-miner: Disable monitoring when dealing with unknown monitors · 5a318139
      Carlos Garnacho authored
      We just can't do safe assumptions about its limits or behavior, seems
      best to turn monitoring off altogether.
      5a318139
    • Carlos Garnacho's avatar
      libtracker-miner: Remove FEN directory monitor handling branch · b2c67b93
      Carlos Garnacho authored
      The code supporting Solaris file monitors went away from glib ~2y
      ago.
      b2c67b93
    • Carlos Garnacho's avatar
      libtracker-miner: Remove ifdef around useful feature · e59e14b0
      Carlos Garnacho authored
      The mentioned bug got fixed ~6y ago, but the changes making
      use of the feature for some reason got stuck under a define
      that's never defined.
      
      This is an useful feature, so rely on it without further ado.
      e59e14b0
    • Carlos Garnacho's avatar
      libtracker-miner: Remove dead TrackerMonitor code · 671a599f
      Carlos Garnacho authored
      The PAUSE_ON_IO feature required someone to notice it and
      modify tracker code to #define instead of #undef. I discovered
      it before, and chose to remove it instead.
      671a599f
    • Carlos Garnacho's avatar
      libtracker*: Lower g_message()s to g_debug() · d7839966
      Carlos Garnacho authored
      This is library code, so let's use g_debug() which obeys G_MESSAGES_DEBUG,
      instead of g_message() which shall be printed unless there is an special
      log handler that filters those out.
      This code may run on 3rd party code, where we can't trust we'll have
      a log handler that catches those from going to stdout.
      d7839966
  9. 11 Jul, 2017 1 commit
  10. 20 Nov, 2016 1 commit
  11. 27 Mar, 2016 1 commit
  12. 06 Jul, 2015 1 commit
    • Philip Withnall's avatar
      libtracker-miner: Keep a monitor on root index tree files on deletion · 0ca8361f
      Philip Withnall authored
      If Tracker is running with some index-recursive-directories set (for
      example, ~/Music), and one of those directories is moved, then the file
      monitor watching for its existence is deleted. This means that if it is
      then moved back to the location listed in index-recursive-directories,
      its renewed existence is not detected, and its contents are not
      re-indexed.
      
      Fix this by keeping a monitor around on a directory if that directory is
      listed as an index tree root, even if the directory is deleted.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=750394
      0ca8361f
  13. 31 May, 2015 1 commit
  14. 13 Jan, 2014 1 commit
  15. 19 Nov, 2013 1 commit
  16. 16 Nov, 2012 1 commit
  17. 07 Dec, 2011 3 commits
  18. 16 Jun, 2011 1 commit
    • Carlos Garnacho's avatar
      tracker-monitor: translate CREATE(a)+MOVE(a->b)=UPDATE(b) · 35bdcb09
      Carlos Garnacho authored
      Fixes NB#251032. Tracker-writeback often creates a temporary hidden
      file that, after modification, is moved onto the original file location,
      This tricked TrackerMonitor so that the create and move operations there
      were translated as a create operation, and create operations are
      compressed with delete events into a noop. So if a quick delete came
      after, TrackerMonitor was emitting no signal for a truly deleted file.
      
      Instead, translate create+move as update, the miners handle creates
      and updates equally, and these won't get compressed with delete
      events, so those are still emitted.
      35bdcb09
  19. 14 Jun, 2011 1 commit
  20. 30 May, 2011 1 commit
  21. 24 May, 2011 1 commit
  22. 13 May, 2011 1 commit
  23. 01 Feb, 2011 3 commits
  24. 19 Jan, 2011 3 commits
  25. 17 Dec, 2010 1 commit