1. 29 Sep, 2017 4 commits
  2. 04 Jun, 2016 3 commits
    • Martin Kampas's avatar
      miner-fs: Fix handling files moved soon after creating · 7902523b
      Martin Kampas authored
      Noticed this when executing functional tests for write-back:
      (tracker-miner-fs:21288): Tracker-CRITICAL **: Could not execute sparql:
       Subject `(null)' is not in domain `nfo:FileDataObject' of property
      This warning happens in item_move() when the source just didn't have
      time to be indexed. One example:
      copy ("file.txt", "temp_XYZ.file.txt")
       - received G_FILE_MONITOR_EVENT_CREATED ("temp.file.txt")
       - received G_FILE_MONITOR_EVENT_CHANGED ("temp.file.txt")
       - received G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT ("temp.file.txt")
      modify ("temp_XYZ.file.txt")
       - received G_FILE_MONITOR_EVENT_CHANGED ("temp.file.txt")
       - received G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT ("temp.file.txt")
      mv ("temp_XYZ.file.txt", "file.txt")
       - received G_FILE_MONITOR_EVENT_MOVED ("temp.file.txt", "file.txt")
       - emitted  ITEM_MOVED ("temp.file.txt", "file.txt")
      It was already handled in item_move() in past, but removed with eef0e7f3
      (libtracker-miner: Remove useless code) after previously misidentified
      as useless in scope of ee58e679 (libtracker-miner: Add compat layer for
      The comment from ee58e679 """FIXME: This situation shouldn't happen from
      a TrackerFileNotifier event""" simply cannot be satisfied: no way to get
      "temp.file.txt" indexed before ITEM_MOVED is processed - the file
      disappears too fast.
    • Carlos Garnacho's avatar
      libtracker-miner: cater for unbound nfo:belongsToContainer when moving items · e5f565fb
      Carlos Garnacho authored
      Fixes warnings when moving indexing roots around. This query expects this
      property to be bound, resulting in no-op if that's not the case (e.g.
      indexing roots), later reinsertions of nie:url and other properties with
      max cardinality=1 trigger the whole update failure, because those weren't
      properly removed.
    • Carlos Garnacho's avatar
      libtracker-miner: Insert into the right graph when moving items · b7aa32c8
      Carlos Garnacho authored
      The query to update parent-dependent data was using the source file
      urn as a graph urn.
  3. 05 May, 2016 1 commit
  4. 14 Mar, 2016 2 commits
  5. 24 Feb, 2016 1 commit
  6. 15 Feb, 2016 4 commits
  7. 28 Jan, 2016 3 commits
    • Carlos Garnacho's avatar
      libtracker-miner: Do not insert partial/empty sparql on error · 7c74b48b
      Carlos Garnacho authored
      The check for these errors was done specifically so we could still
      insert (even if incomplete) data on tracker-extract failures, when
      we used to communicate with it directly from tracker-miner-fs.
      Nowadays, tracker-extract is a TrackerDecorator, and tracker-miner-fs
      should most likely receive only errors here on ENOENT and other errors
      that affect the file and its info as a whole. In these situations
      we end up with a task with a completely empty sparql string, which
      doesn't help much here.
    • Carlos Garnacho's avatar
      libtracker-miner: Pass a builder in UPDATE state to ::remove-file · acbb1d95
      Carlos Garnacho authored
      A stateless TrackerSparqlBuilder is not that useful, because there's
      no API to push the desired state. A TrackerSparqlBuilder created
      through tracker_sparql_builder_new_update() will allow us to
      open delete and insert statements, which is what we want here.
    • Carlos Garnacho's avatar
      libtracker-miner: Remove children recursively from queues on directory deleted · bd1d178a
      Carlos Garnacho authored
      We use to emit ::file-deleted on topmost directories only when deleting a
      directory tree. This means we have to remove children recursively too, because
      we'll otherwise leave stale items that are not direct children of the directory
      we notified upon.
  8. 17 Jan, 2016 1 commit
  9. 11 Jan, 2016 1 commit
  10. 02 Dec, 2015 1 commit
    • Carlos Garnacho's avatar
      libtracker-miner: Optimize move operations · c5544cfb
      Carlos Garnacho authored
      Instead of creating one delete+insert per file (indirectly) contained
      in a folder, do it all at once in a DELETE...INSERT...WHERE. We only
      now need to query and block if we're running a thumbnailer service,
      which should be most uncommon.
      This makes the whole update to happen in a much tighter loop within
      tracker-store, eg. helps reduce the time spent in processing the
      renaming of a linux kernel tree (51964 elements) from 23s to 12s.
      (as measured locally by tracker-miner-fs on a previously idle
  11. 25 Nov, 2015 1 commit
  12. 23 Nov, 2015 1 commit
  13. 18 Aug, 2015 1 commit
  14. 21 Jul, 2015 2 commits
  15. 05 Jul, 2015 1 commit
  16. 03 Jul, 2015 1 commit
    • Philip Withnall's avatar
      tracker-miner-fs: Fix a completion check when removing the final task · d12df896
      Philip Withnall authored
      Depending on how mining goes, this path might be the last one taken
      before the miner is ready to go idle again. However, the check on the
      task pool size is guaranteed to be false because the task which
      item_add_or_update_continue() was called on has not yet been removed
      from the pool — that’s done directly below.
      Fix that by removing the task from the task pool before checking whether
      the pool is empty.
      This fixes stalls in tracker-miner-fs where `tracker-control -S` would
      show the following for ever (when running with
      index-recursive-directories set to a non-empty list):
         1%  File System - Crawl finished for directory 'blah'
      Previously, the only way to fix this was to pause and then resume the
  17. 17 Mar, 2015 1 commit
    • Carlos Garnacho's avatar
      libtracker-miner: Invalidate the IRI of just inserted elements · c390dbaa
      Carlos Garnacho authored
      This allows us to be smarter about when to look up the IRI on the database.
      If a file is created and being slowly written to (eg. downloads),
      ::file-created will be emitted for the file eventually, but the updates
      will keep the file instance alive on the TrackerFileSystem.
      In this case we attempted to be smart and avoid querying needlessly the
      database for the IRI, which resulted on a mistakenly NULL IRI, and on
      an attempt to "create" the item again, even though it existed. This
      resulted in "UNIQUE constraint" errors.
      One thing we can do is "invalidating" the IRI, so the next time we
      call tracker_file_notifier_get_file_iri() on it, a query is forced only
      in these situations, this will make later updates happy with the right
      If the updates are too slow, and the file happens to be flushed out
      of the TrackerFileSystem (all non-directory files do), the next update
      would trigger again its insertion, and the IRI would be queried again,
      so we're safe in that regard.
  18. 20 Dec, 2014 2 commits
  19. 15 Dec, 2014 3 commits
  20. 10 Dec, 2014 1 commit
  21. 27 Oct, 2014 2 commits
  22. 25 Sep, 2014 1 commit
  23. 05 Sep, 2014 1 commit
  24. 26 Aug, 2014 1 commit
    • Martyn Russell's avatar
      libtracker-miner: Fix reference leak with TrackerTaskPool · 05450979
      Martyn Russell authored
      The leak occurred because tracker_sparql_task_new_with_sparql() was being
      called but the returned TrackerTask* was not being unreferenced anywhere and
      the call to tracker_sparql_buffer_flush() with the new task was taking its own
      references internally.
      Took this opportunity to make the code here easier to follow:
      - do_process_file() is now merged into item_add_or_update()
      - item_add_or_update_cb() is renamed to item_add_or_update_continue() so it's
        obvious it is called from tracker_miner_fs_file_notify().
      - renamed various variables to make the code easier to follow.