Related Objects
General strategy:
- Have a config with black- or white-listed filesystems (fuse.*)
- Connect to Solid to receive a signal when /etc/mtab changes
- On mounts add mountpoint to baloo's excludedFolders cache
- On unmounts do nothing
Status quo:
- Failing unit test: Done (create a temporary vault and mount it)
- Implementation: Lacking (Cannot receive appropiate signal yet)
What's wrong with a .balooignore file in the root of the vault? Tracker uses .trackerignore.
If you want a manual workaround, just add the vault path to excludeFolders.
If you want a proper fix, handle encfs etc. properly in baloo.
The default path for vaults to be mounted to is ~/Vaults; a naive solution would be to ship Baloo with an exclude rule for ~/Vaults. A slightly smarter approach would be for Plasma Vaults itself to add such a rule for whatever mountpoint is chosen during new vault creation.
As a stopgap measure blacklisting ~/Vaults is probably ok.
Long term, blacklisting *all* encrypted file systems IMHO is the way to go, as this is an information leakage.
Of course, if the complete home is encrypted, i.e. content and index reside in the same encrypted volume, home should still be indexed.
@smithjd, since I know you expressed interest in interested in fixing this issue, would you like to become the assignee of this task and implement the following:
- Short-term: by default, ship an exclude entry for ~/Vaults
- Long-term: don't index anything in an encrypted volume that doesn't have the index located in it
- Super long term: split the index so that it can live in multiple locations, and store an encrypted disk's index inside that disk, then allow the contents to be indexed again
Does this sound sane?
A slightly smarter approach would be for Plasma Vaults itself to add such a rule for whatever mountpoint is chosen during new vault creation.
What about exposing these config options on dbus? ("includeFolders"),("excludeFolders")
That would make for 4 new entries (add/remove for each) on the org.kde.baloo.main interface.
I'm not technically knowledgeable to offer an opinion on that, so I will defer to @bruns.