http://bugzilla.opensuse.org/show_bug.cgi?id=1175637 http://bugzilla.opensuse.org/show_bug.cgi?id=1175637#c9 Nick Dordea <ndordea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ndordea@gmail.com | |) | --- Comment #9 from Nick Dordea <ndordea@gmail.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.