Rationalize `tracker index` command and the IndexFile and IndexFileForProcess API
Inspired by #122 (closed) I've been looking at the on-demand indexing methods.
Currently the behaviour is as follows:
-
IndexFile
called with a file:- Metadata from the file is inserted into the store, the file is not monitored for changes, metadata is saved forever.
-
IndexFile
called with a directory:- Metadata from all files is inserted into the store, they are monitored for changes until tracker-miner-fs shuts down, then metadata is saved forever.
-
IndexFileForProcess
called with a file:- Same as
IndexFile
- Same as
-
IndexFileForProcess
called with a directory:- Same as
IndexFile
, but: if the app which called the method disconnects from the bus before tracker-miner-fs shuts down, metadata from all files is removed again from the store.
- Same as
The configuration also affects this functionality -- any filetypes in the ignorelist will be ignored.
I can see the following use cases for these functions:
- An app wants to do on-demand indexing and monitoring of a removable device, only while the app is open and the device is connected.
- An app wants to enable indexing and monitoring of a location that isn't configured for indexing.
- A user wants to enable indexing and monitoring of a location that isn't configured for indexing.
Here are some more dubious use cases:
- A user wants a location to be indexed but not monitored, so that stale metadata will stay in the store forever.
- A user wants to work around a problem in tracker-miner-fs by manually reindexing something when it failed to notice a change.
- A developer wants to trigger re-indexing of a file without changing the file, in order to trigger a bug.
I think usecase 1 (on-demand indexing of a removable device) is served by IndexFileForProcess. Two small problems that we should fix:
- we don't make it clear that all metadata inserted by IndexFileForProcess will be deleted again when the caller exits. Maybe renaming the function would help.
- we don't delete the data if tracker-miner-fs exits before the caller.
Use case 2 and 3 are more tricky. The current tracker index
command just processes a file/directory and then leaves it to go stale. We might do better if we changed tracker index
to actually modify the 'index-recursive-directories' setting. However:
- that only works for directories, not for files.
- there's a risk that the user could end up with a crazily long config if they manually index lots of locations. BUT, there's already a risk that they could end up with bad search results due to old manually-indexed data.
Use case 5 might also be supported well if we fix #122 (closed)
The ReindexMimeTypes command also seems dubious, incidentally -- the docs say: 'This is usually used when installing new extractors which support mime types previously unsupported', but we shouldn't require users to manually call a function to enable new Tracker features.
The tracker index
command also deals with backup/restore, which seems to be broken in 2.x, and we could either remove or implement as a separate command.