https://bugs.kde.org/show_bug.cgi?id=360834
Knut Hildebrandt <knut.hildebra...@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knut.hildebra...@gmx.de --- Comment #5 from Knut Hildebrandt <knut.hildebra...@gmx.de> --- Hey Martin, since you marked https://bugs.kde.org/show_bug.cgi?id=344242 a duplicate of this I continue here. In the other bug report I have written about my experience with data loss and described a workaround to make sure that data - in my case emails - will be copied were they belong - in my case local mail folder. Nevertheless one problem remained, the growth of ~/.local/share/akonadi/file_db_data. After a couple of weeks it holds again tens of thousands of items. After reading what you recommended to Guido I also ran "akonadictl fsck" which brought up quite a few items without RID. But it also said it had found loads of items without a reference in the database. Unfortunately I did not redirect the output to a file and thus most of it is lost. What I still could see are many entries like this: Migrated part 1324911 to new levelled cache When I started it again I got following output: [knut@chakra-pc ~]$ akonadictl fsck Looking for resources in the DB not matching a configured resource... Looking for collections not belonging to a valid resource... Checking collection tree consistency... Looking for items not belonging to a valid collection... Looking for item parts not belonging to a valid item... Looking for item flags not belonging to a valid item... Looking for overlapping external parts... Verifying external parts... Found 1946 external files. Found 1944 external parts. Found unreferenced external file: /home/knut/.local/share/akonadi/file_db_data/771220_r2 Found unreferenced external file: /home/knut/.local/share/akonadi/file_db_data/771240_r1 Moved 2 unreferenced files to lost+found. Checking size treshold changes... Found 0 parts to be moved to external files Found 0 parts to be moved to database Looking for dirty objects... Collection "Search" (id: 1) has no RID. Collection "OpenInvitations" (id: 28495) has no RID. Collection "DeclinedInvitations" (id: 28496) has no RID. Found 3 collections without RID. Item "649909" has no RID. . here came many more RID entries . Found 87 items without RID. Item "499424" has RID and is dirty. Found 1 dirty items. Migrating parts to new cache hierarchy... Consistency check done. When I checked ~/.local/share/akonadi/file_lost+found I saw that most of the files that had been in "file_db_data" before invoking "akonadictl fsck" were moved there. Now "file_lost+found" holds more than 2GB of files whereas "file_db_data" only holds less than half a GB. Now I wonder it it is save to delete all the files in "file_lost+found" to get disk space back? Or will this cause loss of data? Deleting files in "file_db_data" caused massive data loss. Knut -- You are receiving this mail because: You are watching all bug changes.