| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=794496
|
|
|
|
|
| |
This triggered a warning with meson 0.46 and will be treated as an error
by future versions.
|
|
|
|
| |
deprecated
|
|
|
|
| |
This was causing the command to fail.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=796104
|
|
|
|
|
|
|
|
|
|
| |
This script dates from a long time ago when Meson lacked ways to install
generated headers.
This fixes an issue where `ninja install` in tracker.git triggers a
rebuild of lots of stuff from tracker-miners.git, which happened because
the mtime of the installed generated headers would become newer than the
build files in tracker-miners.git and cause ninja to rebuild them all.
|
| |
|
|
|
|
| |
It’s going to be confusing gettext when we port Tracker away from intltool.
|
|
|
|
|
|
|
|
|
| |
previous commit (66a6dc) refactors code, but some lines missed the
refactor. This commit fixes the oversight of those lines.
Signed-off-by: Simental Magana, Marcos <marcos.simental.magana@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793282
|
|
|
|
|
|
|
|
|
|
| |
The agressive VACUUM on shutdown is the cause for the reported slowness
in tracker-store restarts. Let's be a bit more conservative, and only
trigger VACUUMing when the database file gets hideously large (4GB).
There is the remote possibility that a database is still larger than
4GB after VACUUM. I'll just make it suck at the moment and do the same
frequent VACUUMs we get currently.
|
|
|
|
|
|
|
|
|
|
|
|
| |
On monitor events on directories we used to trigger a full crawling, and
only notified the directory during recursive handling. However other monitor
events may happen immediately on the child, which would get queued
immediately before the parent folder (which is being idly crawled).
Emit ::file-created immediately here in order to ensure correct ordering
in the TrackerMinerFS queue. If notifier_queue_root() ends up notifying
about the file again, the event would get eventually discarded or simply
handled as an update.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=793061
|
|
|
|
|
|
|
|
|
| |
This enables enumeration of non-native files because GVfs doesn't like
to mix asynchronous & synchronous GFileEnumerators. If an enumerator
is obtained through one API variant, then it should be used via the
same API variant.
https://bugzilla.gnome.org/show_bug.cgi?id=792337
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=792337
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=792691
|
|
|
|
|
|
|
|
| |
The GVariant type string "i" refers to a signed 32-bit integer.
Therefore, gint32 is a much safer bet than gint, whose size is not
guaranteed across all platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=792301
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=791067
|
|
|
|
|
|
|
|
| |
We were in some places checking the value of HAVE_LIBICU as a boolean
and in others checking whether it was defined. This is broken because
when it is defined to 0 we mix up the code paths completely.
Fixes the Meson build since d5e9ce54196d5c9086423e688c8014c1225b858b.
|
|
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=791433
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
|
|
|
|
|
|
| |
Based on a patch by Jeremy Bicha <jbicha@ubuntu.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=790373
|
|
|
|
|
|
|
|
|
|
|
| |
library"
This reverts commit 9afd9afc67a2ccbe4d8eee59a4b9be796e794f2d.
This is no longer needed, instead we have renamed libtracker-common to
libtracker-miners-common in tracker-miners.git so that the two libraries
don't conflict when tracker.git is built as a subproject of
tracker-miners.git.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Folders being configured as indexing roots should win over any filter
that might apply. The basename based filters correctly skip configured
roots already, so do the same with the directory content filter.
The practical side effect is that .git folders are now allowed on the
directories configured in tracker-miner-fs (homedir and XDG dirs most
usually). Tracker tries to stay out of source code trees which are a
source of pointless grinding, but there's legit usecases to have these
folders under git management:
- User setups to bring in essential files across machines
- Collections managed through git-annex
Those are worth handling, even if the question also applies to folders
found recursively and the .git heuristic proves limited.
https://bugzilla.gnome.org/show_bug.cgi?id=790284
|
|
|
|
|
|
| |
We don't add a "file", but a whole RootData that may be recursively
crawled. Also, make the crawl_directories_start() from this function,
since that's the next thing to do in every calling place.
|
|
|
|
|
| |
If we hit some early return conditions, the RootData would be
leaked.
|
|
|
|
|
|
|
|
|
| |
As both places doing this iterate directories one by one, we
can optimize GFile interning by providing an already interned
common parent.
This eases the GNode lookups in TrackerFileSystem, as we already
know the most direct parent GNode the file should have.
|
|
|
|
|
|
| |
It doesn't bring any gains to use interned files when adding
directories to the TrackerMonitor. Just use the GFile we get
and avoid interning the directory this soon.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation catered for GFiles being used from multiple
TrackerFileSystem instances. This is clearly overkill as we most
often have one (one miner per process) and even if there's multiple
miners in the same process, the Gfile instances are not
interchangeable.
This can just go away, and we instead ensure to create a duplicate
of the GFile if it actually belongs to another TrackerFileSystem,
which again is extremely unlikely.
|
| |
|
|
|
|
|
| |
Those have been unused for a long time. We now only pass sparql
around as strings.
|
|
|
|
| |
Those have been unused for quite some time now.
|
|
|
|
|
| |
There were other places that didn't ensure that TrackerFileNotifier used
interned files when emitting ::file-* signals.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We just can't do safe assumptions about its limits or behavior, seems
best to turn monitoring off altogether.
|
|
|
|
|
| |
The code supporting Solaris file monitors went away from glib ~2y
ago.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
We deemed the directory as bad whenever any file didn't match the
filter, but files that don't match the filter should not trigger
it in one way or another.
|
|
|
|
|
|
| |
The assumption is that TrackerFileNotifier emits files that are
currently interned in the TrackerFileSystem. This event handler
broke the assumption in a couple of places.
|
|
|
|
|
|
| |
This is doubly cached in the TrackerFileSystem and as GObject qdata (and
obtained from the former in that case). Let's just rely on the former for
all.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Despite the order implied here, the source/dest GFiles were emitted in
the inverse order. Funnily tracker-miners and everything else around
gets the order right, so it's really the header definition what is
backwards here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace all 4 queues for the different create/update/delete/move
events with a single queue that contains generic QueueEvent
structs. The GList node of the last event is stored as GFile
qdata, in order to perform fast lookups when coalescing events.
queue_event_coalesce() will attempt to convert any two events
into less than that, it does rely on merging two events with
no related events in between, those should be coalesced (or
attempted to) when they arrive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TrackerFileNotifier guarantees that parent files are emitted before any
children, the other usecase that this used to cover are explicit
tracker_miner_fs_check_file() calls which used to also index parent
directories, but it doesn't do that anymore since quite some time.
So the only remaining case where we could end up with a file whose parent
is neither being currently processed nor indexed is actual bugs. In that
case, the bug likely won't go away by trying harder, which leads to logging
for every child file, as they'll fail in cascade.
Let's be less stubborn here, warn (once!) about the missing file and ditch
all pending events happening on/inside it. People love filing bugs about
tracker logging stuff, so I don't think bugs will go unnoticed anyway.
|
|
|
|
| |
Seems quite fit to manage priv->current_index_root.
|
|
|
|
|
| |
We can steal data sooner in order to avoid unsetting the data in the early
return path.
|
|
|
|
|
|
|
|
|
|
| |
TrackerFileNotifier actually triggered mtime checks more often than
necessary. All of the sparql queries can be skip, also storing the
filesystem mtimes (because no sparql mtimes will be queried to
compare with).
We just need setting up our TrackerFileSystem tree, and adding
directory monitors, so do this bare minimum.
|
|
|
|
|
| |
We always perform those one directory at a time, so drop the array/len
arguments from directory content queries, and just pass a GFile around.
|
|
|
|
|
| |
We currently always process directories one by one, but we preserved the
variable depth handling. This can be simplified away.
|
|
|
|
|
|
|
|
|
| |
It was always called with depth=1 (return just direct children of the
given folder), so make this the default. Admittedly, the "crawler" name
is a bit of an stretch now.
The TrackerCrawler tests have also been removed the recursive tests,
since that's not possible anymore.
|