In [1] it's stated that "If the values "inserted" into the text
columns as part of a 'delete' command are not the same as those
currently stored within the table, the results may be unpredictable."
It's to be assumed only inserting ftsid is unpredictable. We
have no way for a proper delete because files are not immutable
or may have been deleted.
For now the index will contain entries for files that don't exist.
They won't appear in search results as they won't be joined
in the query.
[1] https://www.sqlite.org/fts5.html#the_delete_command
Most users are not to be expected to be familiar with
sqlite's FTS syntax. It also leads to unnnecessary
arrows in some instances.
So wrap every space separated word in quotes, unless
it's already in quotes. Then we just escape those with
double-quotes.
We never used the content copy we stored. It only wasted space.
Update scheme so we do not store the content anymore. Switch
to contentless FTS approach
Running migrations is okay for initialization. However, doing
it here might take ages, so the GUI simply would not show up.
Therefore, migration must be done by the CLI or GUI and they
should show that migrations are running
We get OK_WASEMPTY from the processor when there
usually should be something. Rarely, this is not the case.
Let the callers know about this state at least
Scan the top directory to collect paths for the threads. This
way we don't launch threads for paths without subdirs. Secondly,
large trees like usually $HOME will be scanned by multiple threads
at first.
Nevertheless, ParallelDirScanner can be improved still as threads may
run quickly out of work, so we may end up with only one anyway again
Sigh. quazip changed the lib name, include locations, etc. from version 1.
Some distributions only have 0.9. Some only 1.x and so some packages break,
so they simply patch it when building the package.
Luckily, nothing we use from quazip is affected from an API perspective.
So detect if there is quazip1, then use pkg-config to link that, else do it like before.
Not entirely ideal, since we may want to search for 'cake', and look at
a preview for 'cake.txt' even if there is no 'cake' inside.
But this will do for now
Mountpaths indicate mount points of external devices. Files
located under such paths should not be removed on sync, because
they may have not been deleted, but are just inaccessible right now.
This makes sense in general, however it also avoids a race condition.
The dirscanner may finish before the filescanworkers for the files
run, this then signals the whole indexer has finished.
