> No. It does store any info. Does this mean that 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? > 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. I'm not sure this is a good idea. Or potentially reporting non-changed files to the client when the snapshot was not recent enough for the requested timestamp. > Be careful here. > > * Silently failing is not always a good idea When statistics are concerned, it is always ok to fail Joking, but we can not do any better than that. > * Making file Indexing mandatory for statistics also seems a little bit Indexing would be mandatory (or the separated service) just for the moving/deletion detection - the rest would work as before. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76 On 21 October 2014 17:18, Vishesh Handa <m...@vhanda.in> wrote: > > On Tue, Oct 21, 2014 at 11:22 AM, Ivan Čukić <ivan.cu...@kde.org> wrote: > >> One thing to ask here is 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? >> > > No. It does store any info. > > Still, baloo is not off the hook - if we want to detect the file moving >> and >> deletion (as suggested by the guy behind baloo :P), at least for the >> indexed >> files, we need baloo to somehow tell us what was moved/deleted. >> >> This could be implemented in a few different ways that would all have >> some >> drawbacks: >> 1 - baloo sending signals - big drawback would be that if the clients >> miss out >> an event, the database would become inconsistent; >> 2 - saving baloo ids along files in kamd - drawback is that baloo becomes >> tied >> to sqlite (as you mentioned); >> 3 - baloo saving information about what has moved/deleted so that a >> client can >> ask for all events that happened since some timestamp - drawbacks here >> are >> that the clients need to regularly check for the updates meaning they >> will >> most likely have at least a bit out of date information >> > > 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. > > 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 metadata, but that can be improved. I'm not saying that we make btrfs a > dependency for Plasma, I'm just throwing ideas out there which was can use > IF the user is on btrfs. > > >> 4 - combination of 1 and 3 - it would be the most complex implementation, >> but >> it would work properly (distributed dbs are evil ) >> >> And, an additional problem is what to do about the files that are not >> indexed >> by baloo? Should it silently fail or what? For the statistics, it would >> be >> (imo) ok to fail silently, but for activity linking, it might be nice to >> show >> a warning message to the user. >> > > Be careful here. > > * Silently failing is not always a good idea > * Making file Indexing mandatory for statistics also seems a little bit > risky. > > -- > Vishesh Handa > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
