1. 06 May, 2019 1 commit
  2. 01 May, 2019 1 commit
    • Sam Thursfield's avatar
      tracker-extract-text: Correctly report errors back to the caller · 08f4af62
      Sam Thursfield authored
      The tracker_extract_get_metadata() function should return FALSE if
      an error occurs reading the file. The tracker-extract-text module would
      return TRUE in all cases.
      
      This was causing intermittent failures in the functional-tests, as the
      following situation could occur:
      
        1. file2.txt is created
        2. tracker-miner-fs sees file2.txt and processes it
        3. file2.txt is deleted (or moved into an unmonitored directory)
        4. tracker-miner-fs sees the deletion and removes its resource from
           the store
        5. tracker-extract sees the created notification for file2.txt and
           tries to process it
        6. the tracker_extract_get_metadata() incorrectly returns TRUE
           (success), so tracker-extract recreates the deleted resource
      
      This problem was being detected in the functional tests and was
      causing intermittent failures.
      
      This hopefully fixes: GNOME/tracker-miners#56
      08f4af62
  3. 24 Apr, 2019 2 commits
  4. 31 Mar, 2019 3 commits
  5. 18 Mar, 2019 1 commit
  6. 11 Feb, 2019 2 commits
  7. 09 Feb, 2019 1 commit
  8. 18 Nov, 2018 1 commit
  9. 13 Nov, 2018 1 commit
  10. 30 Sep, 2018 2 commits
  11. 10 Sep, 2018 1 commit
  12. 09 Sep, 2018 3 commits
  13. 30 Aug, 2018 1 commit
  14. 29 Aug, 2018 1 commit
  15. 26 Aug, 2018 2 commits
  16. 24 Aug, 2018 1 commit
  17. 15 Aug, 2018 3 commits
  18. 11 Aug, 2018 2 commits
    • Sam Thursfield's avatar
      Allow use of domain rules that aren't installed into /usr · 5a58a451
      Sam Thursfield authored
      Currently Tracker domain rules must be installed inside Tracker's data
      directory (usually /usr/share/tracker). This is limiting as it means
      only system packages can add them. A program installed into /opt is
      unable to use a custom domain, for example. Since Tracker is implemented
      as a system of daemons, it's not particularly straight forward to work
      around this by setting XDG_DATA_DIRS= to point somewhere non-standard
      either.
      
      This patch removes this restriction in a simple way: it allows users to
      pass a full path to the domain rule, rather than just the base name.
      5a58a451
    • Sam Thursfield's avatar
      tracker_domain_ontology_get_domain() should return only the domain name · d7076fff
      Sam Thursfield authored
      We should be consistent about what the name of a Tracker domain actually
      is. In the domain rule we specify Domain=org.freedesktop (for the
      default rule) or Domain=org.example.App (for a custom domain). But
      internally tracker_domain_ontology_get_domain() would return
      org.freedesktop.Tracker1 or org.example.App.Tracker1, i.e. the domain
      name now has '.Tracker1' appended.
      
      This does make sense in most cases, but it means there's no way to get
      the actual name of the domain from a TrackerDomainOntology object. This
      commit changes the existing function to not append '.Tracker1' in the
      value it returns, which means that function can now be used to get the
      base name of the domain. The assumption is that callers are normally
      appending stuff to this base name anyway so it's not much extra effect
      to also append the '.Tracker1' component if needed.
      
      libtracker-common is internal to Tracker so this doesn't constitute a
      public API break.
      d7076fff
  19. 04 Aug, 2018 1 commit
  20. 03 Aug, 2018 4 commits
  21. 23 Jul, 2018 1 commit
    • Carlos Garnacho's avatar
      tracker-extract: Tag errored out files as to be ignored · d92476bf
      Carlos Garnacho authored
      The TrackerExtractPersistence stuff takes care of marking files as ignored
      whenever those trigger crashes. However for the files that simply error out
      we just add those to a runtime blacklist, which gets forgotten on next runs.
      
      Those will trigger message/warning logging each time tracker-extract is
      restarted, which is more often now. Just mark those as failures as it'd
      happen with files resulting in crashes. We need to think how these files
      are generically retried after extractor fixes/updates, but that is also
      missing for crashing files.
      
      GNOME/tracker-miners#6
      
      Closes: #6
      d92476bf
  22. 20 Jul, 2018 1 commit
    • Sam Thursfield's avatar
      meson: Fix warnings from extractor during functional-tests · a86d55c6
      Sam Thursfield authored
      In order to run tracker-extract without installing it, we set the
      TRACKER_EXTRACT_RULES_DIR path to point to the src/tracker-extract
      directory.
      
      This is problematic because that directory contains lots of stuff
      that isn't .rule files and also contains .rule files for extractors
      which might not be enabled. The result being pointless warnings
      during the tests like this:
      
          ** (tracker-extract:29193): WARNING **: 16:18:11.703: Could not load module '/home/sam/src/tracker-miners/build/tests/functional-tests/../../src/tracker-extract/libextract-libav.so': /home/sam/src/tracker-miners/build/tests/functional-tests/../../src/tracker-extract/libextract-libav.so: cannot open shared object file: No such file or directory
      
      Using Meson it's fairly straightforward to create a separate
      directory in the build tree to contain these files, which fixes
      the warnings.
      
      The same thing could be implemented for Autotools, but it doesn't
      affect the actual functionality of the tests so I haven't spent time
      on it myself.
      a86d55c6
  23. 16 Jul, 2018 3 commits
  24. 01 Jul, 2018 1 commit