Here are a lot of bug reports of Baloo crashing caused by corrupted
database. This patch provide a button in KCM to quickly delete and rebuild index
database.
Details
Diff Detail
- Repository
- R119 Plasma Desktop
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 8109 Build 8127: arc lint + arc unit
I wish this weren't necessary, but I think it's a good idea for the time being.
Can you reduce the button width so it doesn't span the entire layout? It should be as small as possible and right-aligned.
Thanks! This is pretty good as-is, and I can confirm that it works just fine. However once the user presses the button, there's no further feedback, which could encourage them to repeatedly press it again--not a good idea. Maybe while the initial index is being generated, we could display a progress spinner (and a label too) and disable the button. What do you think?
kcms/baloo/kcm.cpp | ||
---|---|---|
208 | This whole section could benefit from a few more line breaks to separate the commands into logical groups. |
Thanks!
- Could we use an inline KMessageWidget instead of a dialog box? Dialog boxes are annoying.
- The text should be something more like "Database is now being rebuilt", since if I'm understanding the code, it will be displayed immediately. So it isn't actually accurate to say that the database has already been rebuilt.
No, I don't want a dialog window of any kind. Just a spinner on the page that says, "Indexing is in progress" or something was what I had in mind. An inline KMessageWidget is okay too. However my major concern was communicating to the user that something happened so they don't click the button multiple times.
If we know the DB is corrupted, and it's just a cache, why do we need a user facing button?
It is also possible to move this function to database corruption handler. One thing I worry about is: if the database corruption is caused by software reason, it will repeat the corrupt-rebuild-corrupt dead loop...
maybe also add an heuristic that if has been automatically rebuilt more than x times in the last y time, stop doing it?
There are many possible ways of corruption:
- non-decodable values
- entries with dangling parent IDs
- IDs of no longer existing documents
- ....
These have different reasons, not all reasons are known and understood, not all corruptions are critical.
There are issues with races in the file system, where items are deleted/created/modified while these are added to the DB. Unfortunately, Qt offers no way to handle it, the only save method is to use the openat/fstatat/... functions. This is possible to fix, but until then, rinse and repeat.
The non-decodable values are hard to handle, this would at least require scrubbing the whole DB or building it from scratch. But until it is known what causes this corruption, we end up in doing it again and again.
Some of these are quite safe to just ignore, but some parts a lacking sanity checks. On the other hand, D12336 is waiting for review for 10 months ...