The usage statistics [kactivities, baloo, ktp, plasma]

[Vishesh Handa]

On Tue, Oct 21, 2014 at 6:42 PM, Ivan Čukić <ivan.cukic at gmail.com> wrote:

> > No. It does store any info.
>
> Does this mean that baloo does not search file names at all?


I'm confused about your question. You'd initially asked "if baloo skips
indexing a file that is in an indexable folder - does it store any info
about the file (name, date etc.) or not".

It does not store any information about that file if it skips indexing it.
The only reason it would skip the file would be if the mimetype was
blacklisted or there were certain exclude filters.

What do you mean by "Baloo does not search file names at all?"

>
>
> > The NTFS file system has something similar. It's called a USN Journal.
> It's
> > their solution to applications being able to see what changed when they
> > weren't running or if they missed some events.
> >
> > I'm not too keen on Baloo doing stuff like this, but we can make
> something
> > new which does stuff like this, and (possibly) make Baloo use it.
>
> +1
>
> This would mean essentially moving baloo's file change detection outside,
> and
> improve its powers a bit?


Yes. Though lets really make sure we absolutely need this before taking
such a drastic step. inotify really is horrible, and until we have an
alternative, it might be prudent to wait.

> I looked into the BTRFS file system about a month ago, and we could
> > hypothetically use its snapshot feature to know what has changed since a
> > particular time interval. Currently btfs-send, sending both the data and
>
> The problem with this is that the snapshots should be *very* frequent
> then.
>

The cool thing about btfs snapshots is that even if they are frequent the
don't consume any space, and are automatically deleted if the user starts
using more space.

Anyway, we probably should not discussing btrfs stuff.

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141021/3a0dcd66/attachment.html>