https://bugzilla.gnome.org/show_bug.cgi?id=787774

It seems recent vala got pickier with passing unsigned to a %d
parameter. It's still right nonetheless, and changing the string
is a needless translation change, so just cast to int.

Sam Thursfield authored Mar 11, 2017 and Carlos Garnacho committed Sep 29, 2017

Commit 53007652 breaks the build with
versions of Vala older than 0.35.6. It's more convenient for people
building Tracker if we use a #if block instead to allow building with
older stable versions Vala.

Confusion between TrackerExtractInfo and TrackerDecoratorInfo, might
induce crashes.

We still do need to query mtime from the symlink itself in order to keep
filesystem accounting happy, so wait for ENOENT while doing
g_key_file_load_from_file() in order to figure out we are dealing with
a broken link (or a no longer existing file, which is also possible). This
avoids spewing any warnings with those.

https://bugzilla.gnome.org/show_bug.cgi?id=786132

tracker-miner-fs does rely in a few places to index local content
exclusively. Make it explicitly ignore non-native mounts, they won't
be indexed anyway, but we can spare trying to create the tracker:Volume
and mount root's nfo:FileDataObject for these.

Fixes nie:url constraint errors and other warnings when trying to deal
with those.

https://bugzilla.gnome.org/show_bug.cgi?id=786132

The volume URN is not meant to be the graph URN, use the tracker-miner-fs
graph instead.

Tracker may end up with nfo:FileDataObject prior to handling monitor
events. Be it leftover data from previous bugs, explicit "tracker index"
calls, or data from some other application.

As we can't be really sure of the data consistence, always fallback to
a URN query so we don't break nie:url UNIQUE constraint (inverse functional
property in SPARQL parlance).

https://bugzilla.gnome.org/show_bug.cgi?id=786132

file_notifier_traverse_tree() has the side effect of deleting mtime data,
as it's presumably not needed anymore, except here. Check whether the
directory was updated before notifying of the files inside, so we can
thoroughly check for deleted content.

https://bugzilla.gnome.org/show_bug.cgi?id=786132

The sparql buffer might get full again with new tasks before the
update_array operation for the current batch returned. In this case
nothing will kick the TrackerMinerFS again, nor the SPARQL buffer
from flushing again. Fix this by just flushing again, the miner
will follow as soon as the SPARQL buffer is below limits.

The checks to notify about indexing having finished on TrackerIndexingTree
roots were mistaking ItemMovedData* with GFile*, which lead to warnings.
This should be harmless, the signal might be possibly emitted before the
move op is dispatched, that's all.

The file might or might not be inserted to the queue, which meant that
the extra ref created outside the call might never dropped if the file
didn't end up inserted again. Fix this by doing the refcount increase
when actually inserting the file back in the queue.

Reported by Jose M. Arroyo <jose.m.arroyo.se@gmail.com>.

Philip Withnall authored Jan 25, 2017 and Carlos Garnacho committed Sep 29, 2017

In the error path, finish_current_directory() was called on `notifier`
before it had been initialised.

Coverity CID: 1397952

https://bugzilla.gnome.org/show_bug.cgi?id=777725

It oddly tried to just keep going, which may result in spurious deletes
or partial inserts. Sounds better to just drop the ball on the directory
at hand, it should be correctly indexed eventually.

On cancellation, the early return would leak the DataProviderData, which
indirectly contains the GFileEnumerator, and thus the directory fd. Just
deal with cancellation like we do with other errors, except we don't want
to warn.

The QUEUE_UPDATED elements where being additionally checked against
the QUEUE_WRITEBACK queue. This was harmless, but potentially confusing.
Spotted through Coverity.

We don't use G_FILE_MONITOR_WATCH_MOVES as it doesn't add much to us,
so make the extra derived event types a no-op.

https://bugzilla.gnome.org/show_bug.cgi?id=787774

See https://bugzilla.gnome.org/show_bug.cgi?id=771765

The same GError may be reused further ahead, which would doubly free
it as it gets non-NULL again to error handling paths.

And allow these to manipulate stdin/out/err. They may close file
descriptors, but they don't grant access to anything the process
wouldn't have already access for, anyway.

Philip Withnall authored Jan 23, 2017 and Carlos Garnacho committed Feb 23, 2017

This makes our seccomp() protection independent of the exact kernel
version Tracker is built against.

https://bugzilla.gnome.org/show_bug.cgi?id=777591

Philip Withnall authored Jan 23, 2017 and Carlos Garnacho committed Feb 23, 2017

This introduces no functional changes.

https://bugzilla.gnome.org/show_bug.cgi?id=777591

Philip Withnall authored Jan 21, 2017 and Carlos Garnacho committed Feb 23, 2017

On older kernels, these syscalls did not exist, so the __NR_* syscall
number definition does not exist for them, and compilation fails. Make
the seccomp rules for them conditional on the syscall numbers existing.

https://bugzilla.gnome.org/show_bug.cgi?id=777591

This is not a string, but a builtin class, so it must be dealt with as
a URI.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

https://bugzilla.gnome.org/show_bug.cgi?id=776117

Those were not being printed, just referenced in the parent resource.
Fixes properties like slo:location being lost on newly indexed photos.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

This is not an string, but a builtin class, so it must be dealt
with as a resource.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

This is not an string, but a builtin class, so it must be dealt
with as a resource.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

This is not an string, but a builtin class, so it must be dealt
with as a resource.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

This is not an string, but a builtin class, so it must be dealt
with as a resource.

https://bugzilla.gnome.org/show_bug.cgi?id=776723

We don't need to generate sparql/turtle for builtin classes
(eg. nmm:flash-on).

https://bugzilla.gnome.org/show_bug.cgi?id=776723

dup2/3 have special requirements, as they can close underlying
fds, they are not allowed on stdin/out/err.

Let's give extractor modules the illusion that they can write
something, they actually can't.

https://bugzilla.gnome.org/show_bug.cgi?id=776117

Modifying those is not allowed though.

https://bugzilla.gnome.org/show_bug.cgi?id=776117