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
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?
This whole section could benefit from a few more line breaks to separate the commands into logical groups.
- 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.
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...
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 ...