Comment # 9 on bug 1175637 from Nick Dordea

Hello,
1)
Just a thought: maybe akonadictl fsck cannot rename/move the files because they
are actually still in use by some process?
And maybe akonadi itself fails to delete them in the first place when it
removes entries from the cache for the same reason? (resulting in those
unreferenced files to exist)

ND) It may be the case .  After upgrade to leap 15.2, when moving emails  to
trash,  kmail/akonadi is very slow and it take a long of time until the move is
done/completed .
That may cause some mismatch between hardening the changes to the the logs vs.
database consistency .

2) 
And for the record: I just ran akonadictl fsck on my system (with latest KDEPIM
and Qt, so not affected by bug#1173759).
It did find 2 unreferenced files in file_db_data, but it successfully *moved*
them to file_lost+found, i.e. they no longer existed in file_db_data
afterwards.
So this seems to be working in general. 
(unless it is a bug in 20.04.2 that got fixed in 20.08.0, but I don't remember
seeing a corresponding change)

ND)My machine indicates that kmail/akonadi are at 20.04.2 level [
Main_Distribution_oss distro]
Would the bug#1173759 change/update the kmail/akonadi 20.04.02 ?

3) Speaking of akonadictl ... 
are there any chances to enhance the akonadictl messages to provide more
information to/for the users .

Those collection numbers, record-ids, etc. do not point to what the users are
dealing with ...
--- folders 
--- email title/date 
So how could we tell KDE support teams what is the "source" of a particular
email ....

Thank you, 
Nick