1. 27 Mar, 2019 1 commit
  2. 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
  3. 02 Mar, 2019 4 commits
  4. 21 Feb, 2019 1 commit
  5. 13 Feb, 2019 1 commit
  6. 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
  7. 05 Dec, 2018 1 commit
  8. 13 Nov, 2018 1 commit
  9. 12 Nov, 2018 2 commits
  10. 13 Oct, 2018 1 commit
    • Carlos Garnacho's avatar
      build: Fixes to docs generation · 86a4a666
      Carlos Garnacho authored
      The docs were not going through gtkdoc-scangobj, and the libtracker-sparql
      docs were just looking in source dir while it should also look for gtk-doc
      comments in generated files from vala.
      
      Now that we're there, use include_directories() to get rid of relative
      paths.
      86a4a666
  11. 12 Oct, 2018 2 commits
  12. 09 Sep, 2018 8 commits
  13. 04 Sep, 2018 4 commits
  14. 29 Aug, 2018 2 commits
  15. 21 Jul, 2018 1 commit
    • Carlos Garnacho's avatar
      libtracker-miner: Coalesce 2 CREATED events · 58cc6255
      Carlos Garnacho authored
      It is not even clear this is possible in real life cases, however the
      standalone tracker-file-notifier tests fall into this (due to IRI not being
      ever set, still this is an async op). In the case of 2 consecutive CREATED
      events on the same file, it would be dealt with in TrackerMinerFS as CREATED+
      UPDATED. This was already harmless, but we can do better and swallow one of
      such events.
      58cc6255
  16. 20 Jul, 2018 1 commit
    • Sam Thursfield's avatar
      libtracker-miner: Fix race which resulted in files being queued out of order · 68381c1d
      Sam Thursfield authored
      The TrackerFileNotifier signals need to be emitted in a heirarchical
      order. If we have this directory heirarchy...
      
          test-monitored/
          test-monitored/file1.txt
      
      ...we must always emit ::file-created for 'test-monitored/' before we emit
      ::file-created for 'test-monitored/file1.txt'.
      
      The tracker_file_notifier_ensure_parents() function ensures that we do
      this, but it would previously not work correctly in situations where
      'test-monitored/' was a configured indexing root, rather than a
      subdirectory of one of the roots.
      
      This was causing the tracker-miners functional tests to randomly fail
      with errors such as this:
      
          ** (tracker-miner-fs:18181): WARNING **: 16:01:00.461: Parent 'file:///home/sam/tracker-tests/tmpDSmsQI/test-monitored' not indexed yet
      
      This is presumably a regression from 2e2dd4f5.
      68381c1d
  17. 15 Jul, 2018 3 commits
    • Sam Thursfield's avatar
      libtracker-miner: Warn when overwriting tasks in the task pool · 13cf183c
      Sam Thursfield authored
      The TrackerTaskPool class and its subclass TrackerSparqlBuffer are
      designed to contain only one task for any given GFile.
      
      If multiple tasks are pushed for the same file some of them might
      not be executed. This leads to issues such as:
      #15
      13cf183c
    • Sam Thursfield's avatar
      libtracker-miner/tracker-miner-fs.c: Fix "Parent not indexed yet" errors · da005c51
      Sam Thursfield authored
      Commit cef502e6 ("Add TrackerMinerFS::move-file vmethod")
      introduced a regression which sometimes led to errors like this:
      
          Tracker-FATAL-WARNING: Parent 'file:///tmp/tracker-miner-fs-test-77E2LZ/recursive/4' not indexed yet
      
      This was causing tracker-miner-fs-test to fail in some cases.
      
      TrackerTaskPool assumes that there is only one task in the pool per
      GFile. When processing item_move() operations this wasn't true because
      we'd create one task for removing the existing dest_file, and another
      task for updating the URL of source_file to point to dest_file. Both
      tasks would be associated with dest_file.
      
      If the SPARQL buffer was flushed after the first task was created and
      before the second task was created, the second task would overwrite
      the first task in the ->priv->tasks hash table, so when the first
      task completed, the second task would be removed from the task pool
      without ever executing.
      
      This would mean that the URL of source_file never got updated to
      point at dest_file, which triggered the "Parent not indexed yet" error
      later on.
      da005c51
    • Sam Thursfield's avatar
  18. 02 Jul, 2018 1 commit
  19. 23 Jun, 2018 1 commit
    • Carlos Garnacho's avatar
      libtracker-miner: Emit ::file-updated on file extension changes · 56c65a71
      Carlos Garnacho authored
      We have no access to past/current GFileInfos, so detect changes in
      file extensions to handle the cases where a change of filename
      results in the file having a different mimetype.
      
      In these cases, ::file-updated should be emitted, so it gets the
      right rdf:types as per its new mimetype.
      56c65a71