[Akonadi] [Bug 344874] username/password not being sent in header
https://bugs.kde.org/show_bug.cgi?id=344874
Thaodan changed:
What|Removed |Added
CC||theodorstormgr...@gmail.com
--- Comment #15 from Thaodan ---
Are there any updates on this?
I'm having the same issue with my nextcloud server.
Accessing the ressource via dolphin works.
The caldav ressource works but not the carddav ressulting in the error below:
{webdav} {"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No
public access to this resource., No 'Authorization: Basic' header found. Either
the client didn't send one, or the server is misconfigured, No 'Authorization:
Bearer' header found. Either the client didn't send one, or the server is
mis-configured, No 'Authorization: Basic' header found. Either the client
didn't send one, or the server is
misconfigured","Code":0,"Trace":[{"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->","args":[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/9\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php","line":105,"function":"call_user_func_array","args":[[{"autoRequireLogin":true,"__class__":"Sabre\\DAV\\Auth\\Plugin"},"beforeMethod"],[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/9\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":466,"function":"emit","class":"Sabre\\Event\\EventEmitter","type":"->","args":["beforeMethod",[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/9\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":254,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/9\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/usr\/share\/webapps\/nextcloud\/apps\/dav\/lib\/Server.php","line":316,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"\/usr\/share\/webapps\/nextcloud\/apps\/dav\/appinfo\/v2\/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"\/usr\/share\/webapps\/nextcloud\/remote.php","line":163,"args":["\/usr\/share\/webapps\/nextcloud\/apps\/dav\/appinfo\/v2\/remote.php"],"function":"require_once"}],"File":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php","Line":168,"CustomMessage":"--"}
--
You are receiving this mail because:
You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 Christophe Giboudeaux changed: What|Removed |Added Resolution|--- |UNMAINTAINED Status|CONFIRMED |RESOLVED --- Comment #4 from Christophe Giboudeaux --- These versions are obsolete, retry with a recent one. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 389607] akonadictl fsck: Show more helpful messages
https://bugs.kde.org/show_bug.cgi?id=389607 --- Comment #8 from Nick --- Hello Martin, Thank you for your email and your comments . I agree that some emails may be lost . I took the time to try making/finding some correlations with what the user sees . - First of all I converted to IMAP as per ip provider's tech-support . So the database contains records from the "old" [maildir? ] system and the new "IMAP" system . Also I had to move the database from my old machine to a new one [ in fact entire /home from old was transfered to the new machine ] So the same userid had acceess to the emails immediately after opensuse leap 15.0 was installed on the new machine ]. I do not know if these changes have any impact [ the hostname was chaged ] - Based on the way akonadictl presents its resulst it(akonadictl) is NOT a user friendly tool . On the contrary the actual reporting scares the user with those messages "no RID" or "dirty" or "records removed from data base and moved in lost-and-found" without at least to ask the user if [s]he wants/agrees with that move . I looked closely to pimitemtable and it seems that the column remoteId is nullable [ i.e. accepts an undefinned/unidentified/unknowm value ]. I believe that the hub of all these issues is not with the database server but with akonadi because switching between MariaDB and Postgresql does not stop the isses from happening. These problems in kmail-database are inherited from the time when kmail was using sqlite . In my humble opinion, the database server does what is told/comanded by the interface between the user and the database---that is akonadi---. It is strange that a such important item as remoteId was translated in a datamodel that accepts it as being nullable . That allows that any event that is not controlled by the code inserts/updates a record as having remoteId NULL, and from this all users' complaints . This assumption does not match the reality . I would like to know how it comes that receiving an email---which has a sender and a receiver--- is recorded in the database with a remoteId of NULL value ? I provide below some info collected from my machine before c;eaning up the records with RID NULl in pimitemtable . You van notice that that record had a valid collectionId but has invalid remoteId . I checked that many other emails with valid remoteId pointer to the same collection Id . I tend to agree with you that . `` However it also could be that Akonadi just messes up big time like in storing the items into remote storage, but somehow failing to store the remote ID or whatever. `` I believe that KDE development should have a look at kmail-database-datamodel if it matches technical-requirements and/or ifv akonadi handles the email requests properly . Also it is very dificult for the user to find any item that is wrong using kmail and not to dig in databse tables . That's the role of akonadictl and/or what ever any USER ORIENTED tools . I believe that akonadikconsole is too powerful for the casual user . At the same time akonadi seem to keep their cards close to the vest . making easy for developers to point to user errors . The users have had it for too long asking and asking and asking and nothing to be done . Thank you, Nick = info from my machine = -- describe pimitemtable -- Field TypeNullKey Default Extra id bigint(20) NO PRI NULLauto_increment rev int(11) NO 0 remoteIdvarbinary(255) YES MUL NULL remoteRevision varbinary(255) YES NULL gid varbinary(255) YES MUL NULL collectionIdbigint(20) YES MUL NULL mimeTypeId bigint(20) YES MUL NULL datetimetimestamp NO current_timestamp() atime timestamp NO current_timestamp() dirty tinyint(1) YES NULL sizebigint(20) NO 0 -- select count(*) from pimitemtable -- count(*) 8691 Record without RID as reported by akonadictl fsck [ 38264 item ... RID ] 38264 5 NULLNULLNULL123 4 2019-04-05 01:12:16 2019-04-05 01:12:16 1 81206 collectionId 123 is one of directories under "Local Folders -- describe pimitemflagrelation -- Field TypeNullKey Default Extra PimItem_id bigint(20) NO PRI NULL Flag_id bigint(20) NO PRI NULL -- select count(*) from pimitemflagrelation -- count(*) 13859 Records associated with id 38264 [ from pimitemtable ] 38264 1 38264 5 38264 12 38264 13 -- describe parttable -- Field TypeNullKey Default Extra id bigint(20) NO PRI NULLauto_increment pimItemId
[Akonadi] [Bug 406856] Found 3734 items without RID.; Item "30024" has RID and is dirty.
https://bugs.kde.org/show_bug.cgi?id=406856 --- Comment #3 from Nick --- Hello Martin, Thank you for your email and your comments . I agree that some emails may be lost . I took the time to try making/finding some correlations with what the user sees . - First of all I converted to IMAP as per ip provider's tech-support . So the database contains records from the "old" [maildir? ] system and the new "IMAP" system . Also I had to move the database from my old machine to a new one [ in fact entire /home from old was transfered to the new machine ] So the same userid had acceess to the emails immediately after opensuse leap 15.0 was installed on the new machine ]. I do not know if these changes have any impact [ the hostname was chaged ] - Based on the way akonadictl presents its resulst it(akonadictl) is NOT a user friendly tool . On the contrary the actual reporting scares the user with those messages "no RID" or "dirty" or "records removed from data base and moved in lost-and-found" without at least to ask the user if [s]he wants/agrees with that move . I looked closely to pimitemtable and it seems that the column remoteId is nullable [ i.e. accepts an undefinned/unidentified/unknowm value ]. I believe that the hub of all these issues is not with the database server but with akonadi because switching between MariaDB and Postgresql does not stop the isses from happening. These problems in kmail-database are inherited from the time when kmail was using sqlite . In my humble opinion, the database server does what is told/comanded by the interface between the user and the database---that is akonadi---. It is strange that a such important item as remoteId was translated in a datamodel that accepts it as being nullable . That allows that any event that is not controlled by the code inserts/updates a record as having remoteId NULL, and from this all users' complaints . This assumption does not match the reality . I would like to know how it comes that receiving an email---which has a sender and a receiver--- is recorded in the database with a remoteId of NULL value ? I provide below some info collected from my machine before c;eaning up the records with RID NULl in pimitemtable . You van notice that that record had a valid collectionId but has invalid remoteId . I checked that many other emails with valid remoteId pointer to the same collection Id . I tend to agree with you that . `` However it also could be that Akonadi just messes up big time like in storing the items into remote storage, but somehow failing to store the remote ID or whatever. `` I believe that KDE development should have a look at kmail-database-datamodel if it matches technical-requirements and/or ifv akonadi handles the email requests properly . Also it is very dificult for the user to find any item that is wrong using kmail and not to dig in databse tables . That's the role of akonadictl and/or what ever any USER ORIENTED tools . I believe that akonadikconsole is too powerful for the casual user . At the same time akonadi seem to keep their cards close to the vest . making easy for developers to point to user errors . The users have had it for too long asking and asking and asking and nothing to be done . Thank you, Nick = info from my machine = -- describe pimitemtable -- Field TypeNullKey Default Extra id bigint(20) NO PRI NULLauto_increment rev int(11) NO 0 remoteIdvarbinary(255) YES MUL NULL remoteRevision varbinary(255) YES NULL gid varbinary(255) YES MUL NULL collectionIdbigint(20) YES MUL NULL mimeTypeId bigint(20) YES MUL NULL datetimetimestamp NO current_timestamp() atime timestamp NO current_timestamp() dirty tinyint(1) YES NULL sizebigint(20) NO 0 -- select count(*) from pimitemtable -- count(*) 8691 Record without RID as reported by akonadictl fsck [ 38264 item ... RID ] 38264 5 NULLNULLNULL123 4 2019-04-05 01:12:16 2019-04-05 01:12:16 1 81206 collectionId 123 is one of directories under "Local Folders -- describe pimitemflagrelation -- Field TypeNullKey Default Extra PimItem_id bigint(20) NO PRI NULL Flag_id bigint(20) NO PRI NULL -- select count(*) from pimitemflagrelation -- count(*) 13859 Records associated with id 38264 [ from pimitemtable ] 38264 1 38264 5 38264 12 38264 13 -- describe parttable -- Field TypeNullKey Default Extra id bigint(20) NO PRI NULLauto_increment pimItemId
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 Christophe Giboudeaux changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |UNMAINTAINED --- Comment #3 from Christophe Giboudeaux --- There's a reason for this obsolete version to be unavailable. Please retry with a recent one. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #5 from Martin Steigerwald --- Thanks, Wolfgang, for letting us know. I hope after release of Debian Buster I can get updated KDEPIM packages for Debian again. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 Wolfgang Bauer changed: What|Removed |Added Version Fixed In||5.10.1 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Latest Commit||https://cgit.kde.org/akonad ||i.git/commit/?id=28f2916db1 ||a2ad98b00250eb4d5dd92ca1548 ||c50 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 Wolfgang Bauer changed: What|Removed |Added CC||wba...@tmo.at --- Comment #4 from Wolfgang Bauer --- (In reply to Martin Steigerwald from comment #1) > akonadictl fsck does not move any files to lost+found, it does not even > create the directory. This should be fixed in 18.12.1 (Akonadi version 5.10.1) though: https://cgit.kde.org/akonadi.git/commit/?h=Applications/18.12=28f2916db1a2ad98b00250eb4d5dd92ca1548c50 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #3 from Martin Steigerwald --- I can confirm this (on a ThinkPad T520 as well:): Akonadi 5.9.3 (from Akonadi/KDEPIM 18.08), no selectable in bugtracker. SUMMARY 'akonadictl stop' does not quit PostgreSQL server. STEPS TO REPRODUCE 1. 'akonadictl stop' while Akonadi and PostgreSQL are running OBSERVED RESULT % akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % akonadictl stop % QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open Error writing to file... [… don't know what this is about …] QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_birthdays_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_indexing_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_contacts_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_notes_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_newmailnotifier_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_mbox_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_followupreminder_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application
[Akonadi] [Bug 389607] akonadictl fsck: Show more helpful messages
https://bugs.kde.org/show_bug.cgi?id=389607 --- Comment #7 from Martin Steigerwald --- Just to confirm that this still happens with Akonadi 5.9.3 (KDEPIM/Akonadi 18.08). Here are some examples of an akonadictl fsck run after switching to PostgreSQL database backend just a few weeks ago: 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 8951 external files. Found 2069 external parts. Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/27/231727_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/37/85637_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/69/230869_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/44/216944_r1 [… >6000 more of those …] Moved 6882 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: 360) has no RID. Collection "DeclinedInvitations" (id: 361) has no RID. Found 3 collections without RID. Item "1144154" in collection "266" has no RID. Item "1144155" in collection "256" has no RID. Item "1144156" in collection "256" has no RID. Item "1144157" in collection "256" has no RID. Item "1144158" in collection "256" has no RID. Item "1144159" in collection "256" has no RID. Item "1144160" in collection "152" has no RID. Item "1144161" in collection "180" has no RID. Item "1144163" in collection "266" has no RID. Item "1144164" in collection "256" has no RID. Item "1144165" in collection "256" has no RID. [… more of those …] Found 43 items without RID. Found 0 dirty items. Looking for rid-duplicates not matching the content mime-type of the parent collection Checking Search Checking Notizen […] Related bugs: - Bug 406958 - Unreferenced files in file_db_data - Bug 406087 - akonadictl fsck incorrectly reports success when file_lost+found folder is absent - Bug 406856 - Found 3734 items without RID.; Item "30024" has RID and is dirty. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #3 from Martin Steigerwald --- Sorry 5.9.3 is KDEPIM/Akonadi 18.08. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 --- Comment #2 from Martin Steigerwald --- Sorry 5.9.3 is KDEPIM/Akonadi 18.08. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Martin Steigerwald --- Setting to confirmed as Bug 406087 - akonadictl fsck incorrectly reports success when file_lost+found folder is absent which is about akonadi fsck not cleaning up those files, shows that this happened to at least another user with Akonadi 5.9.3. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #2 from Martin Steigerwald --- I also reported a bug about those unreferenced files to begin with: Bug 406958 Unreferenced files in file_db_data -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] New: Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 Bug ID: 406958 Summary: Unreferenced files in file_db_data Product: Akonadi Version: 5.9.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Maildir Resource Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de Target Milestone: --- I use Akonadi version 5.9.3 (18.04), not selectable in bug tracker under "Version" SUMMARY I switched to PostgreSQL recently, with a completely clear ~/.local/share/akonadi (well except "db_data" directory switch I created before starting Akonadi for the first time after changing database backend). Just a few weeks later I have: Found 8951 external files. Found 2069 external parts. Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/27/231727_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/37/85637_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/69/230869_r1 [… >6000 of those lines ] Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/76/229676_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/15/85215_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/75/172275_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/36/232836_r1 Moved 6882 unreferenced files to lost+found. This is with Maildir filed by POP3 resources. STEPS TO REPRODUCE I have no idea. Probably just use Akonadi for a while. Maybe related to this is: Out of frustration with Akonadi not responding to KMail requests while doing some background processing I did 'akonadictl stop' and after a minute or so as there was still a PostgreSQL process around… friendly stopped it with a SIGTERM. This may have contributed to the situation. OBSERVED RESULT Unreferenced external files. EXPECTED RESULT No unreferences external files during normal operation. I thought one of the main causes for those have been fixed, but it is still or again happening. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.3 (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION Bug #282160 is related, but kind of outdated, still referencing Baloo. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 Martin Steigerwald changed: What|Removed |Added Ever confirmed|0 |1 CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED --- Comment #1 from Martin Steigerwald --- Thank you for your report, Brendon. I can confirm this with PostgreSQL as database backend. Using same Akonadi version 5.9.3 (KDEPIM/Akonadi 18.04) on Debian Sid. akonadictl fsck does not move any files to lost+found, it does not even create the directory. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406856] Found 3734 items without RID.; Item "30024" has RID and is dirty.
https://bugs.kde.org/show_bug.cgi?id=406856 Martin Steigerwald changed: What|Removed |Added Ever confirmed|0 |1 CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED --- Comment #2 from Martin Steigerwald --- Nick, thank you for your report. I can confirm that this is happening. You may clear up the fsck messages about "item has no RID" with the queries you stated, however… as far as I understand Akonadi assigns a RID once it stored the item in remote storage. For IMAP this would be the IMAP account and for Maildir resource it would be the Maildir. And right now Akonadi's change recorder has no means to retry this failed operation. So items may never end up in the remote storage! Additionally for Maildir I do not get how this operation to store into (the quite local) remote storage could ever fail, as long as the filesystem has enough space. So it could be that those items without RID have not yet been stored to the remote storage and that by deleting them from the database (and if payload stored externally from 'file_db_data') you loose those items (mails, events, contacts, …). So there is a real potential for data loss there. However it also could be that Akonadi just messes up big time like in storing the items into remote storage, but somehow failing to store the remote ID or whatever. I just recently switched from MariaDB to PostgreSQL and already got "Found 43 items without RID." as well as "Moved 6882 unreferenced files to lost+found." (will do a separate bug report about that, since it actually did not even move those files), after just a few weeks of usage. This is with POP3 filling maildir. One thing: On delays during background jobs I sometimes just did "akonadictl stop" and then as PostgreSQL is not stopped completely on my system (yet another bug report), also stop the PostgreSQL process, so this may contribute to the situation. Did you do something similar at times? -- You are receiving this mail because: You are the assignee for the bug.
