Quick bug fix
BUG:390830
ngraham |
Baloo | |
Frameworks | |
Plasma |
Quick bug fix
BUG:390830
(upcoming) make test
No Linters Available |
No Unit Test Coverage |
When creating a Vault you can choose any location for it. ~/Vaults is just the default
This is not a viable approach.
Any vaults created after baloo is configured may be indexed (unless they are inside ~/Vaults, of course).
For the near future I see no other way to exclude vaults from being indexed other than this one. :-(
Maybe when a new vault is configured, it should add itself to baloo exceptions.
Is there any DBus call to baloo to do that?
I was thinking in the same direction. When the mountpoint of a vault is changed (or new) a warning message about baloo's activity should be displayed. The message should be displayed regardless of baloo's enabled state. There's plenty of space for that in the dialogs.
The user could then disable indexing with balooctl or via systemsettings.
IMO configuration of this should be done by Plasma Vault anyway. Baloo's job would be to provide the tools to do it. It's framework after all and should make as few decisions as possible.
Is there any DBus call to baloo to do that?
Nope. It shouldn't be to hard add the respective commands to org.kde.baloo /fileindexer.
File a task for this if it's wanted. (As a prepayment for this :-) it would be nice if somebody would have a look at D10809)
What about users who manually create and mount FUSE-type encrypted directories? Plasma Vault is just a nice interface for this workflow, after all.
A more general approach would be to look at the filesystem type in mount (do we have an API for that?). I'd imagine a user configurable whitelist and/or blacklist (in a config file, not sure that's UI material) would be most flexible. Perhaps there's already similar code in Baloo for handling removable devices or remote filesystems, or is this all based on some hardcoded path heuristics?
Good point.
A more general approach would be to look at the filesystem type in mount (do we have an API for that?). I'd imagine a user configurable whitelist and/or blacklist (in a config file, not sure that's UI material) would be most flexible. Perhaps there's already similar code in Baloo for handling removable devices or remote filesystems, or is this all based on some hardcoded path heuristics?
Not sure, apparently baloo reads /etc/mtab only to disable copy-on-write on btrfs.
Baloo needs a better handling of filesystems. I just started to tackle this (see T8054). When I'm done with that, it should be possible to white-/blacklist specific filesystems.
Did you already look at which approach Tracker uses regarding filesystems? Are they just indexing everything?