Version: 1.7.92 (using KDE KDE 3.3.92) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.4.3 20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) OS: Linux Using disconnected IMAP kmail can delete all local folders if the connection to the server breaks. First I get a dialog window telling me about the timeout, a moment later a lot of boxes popped up (as much as IMAP folders?) and closed immediately. After that all my local folders are gone. This happend more than once. I've always noticed the problem before the gateway came up again and kmail could sync, so I don't know what would happen.
*** Bug 99272 has been marked as a duplicate of this bug. ***
I've tested this a dozen times but can't reproduce the error. Do you have more information? Any special conditions? Do you get more error boxes or only one? What does it say?
I had a similar problem, a few days ago. KMail always stayed at "retrieving folderlist" when checking for mails. So i killed kio_imap4. Killing the slave resulted in popping up hundreds of progress windows without progress and deleting the dimap cache. My kdepim was from Feb 14th.
I'm not shure what exactly tiggers this problem. But I did not have any problems since I disabled interval mail checking. Perhaps that helps. BTW, I did not kill kio_imap4 when I saw the problem.
I've seen the behaviour described in Bug 99272 in three seperate cases All involved a disconnected pcmcia network connector on my laptop. Maybe this helps in reproducing: Sync a large imap repository of mail (usually my mailinglist folders were affected) In the syncing process disconnect your network-connection when "uploading status of messages to the server" stage is reached. Wait for the error message, reconnect network, click continue in the error-mesg-box. I haven't had the time (yet) to investigate. If you need a large amount of mail to test with please connect me, I'd be happy to supply a mailing-list archive for that. (4000+ mesg) I didn't kill kio_imap, my folders do not disappear, no extra dialog boxes pop up. However up to 99% of the mail from a certain folder will disappear. It has also been deleted from the imap server ( I checked before running any dimap rebuild index, etc. options) I suspect that kmail/kontact uploads the status of a partly downloaded folder to the server, deleting any mail not in the dimap cache from the server. Grtz Ramon
I can confirm this problem. I have about 15 mail folders on my (Courier-)IMAP account, with at the moment about 1800 mails in them. It happens regularly that my network is down, and then I get this nice, new, big network connection error box in KMail telling my I could continue or cancel (IIRC). No matter what I press, the usual result is that my local cache gets wiped, sometimes only some folder, but most of the time all of them. By "wiped" I mean that usually all folders except for inbox are completely gone, and inbox is empty. Except for the usual big disconnection error box, I don't get any popups or further error messages, at least none that stay open. The original reporter talks about error popups that immediately close again; that might be the case and I might just never had the chance to see them because KMail is usually in the background. Checking mails again causes KMail to redownload the whole thing, which with 1800 mails takes quite a while. In addition, all filter rules that involve one of the remote folders are reset, since the newly created cached folders seem to get different identifiers... this is the most annoying part of it, because I really don't like checking and fixing all my filter rules several times a day... I am running KMail on a laptop, and I have interval mailcheck enabled. Doing software suspend kills the network connection, and it usually stays down for about half a minute after resuming. That seems to be enough for KMail to cause that problem. It is, however, not directly related to swsusp, since for example tonight my network must have been down for some minutes, and the same thing happened. If you have further questions, please let me know. -- Manuel
On Thursday 24 February 2005 06:46, sputnick@gmx.net wrote: > I am running KMail on a laptop, and I have interval mailcheck enabled. > Doing software suspend kills the network connection, and it usually stays > down for about half a minute after resuming. That seems to be enough for > KMail to cause that problem. It is, however, not directly related to > swsusp, since for example tonight my network must have been down for some > minutes, and the same thing happened. I had exactly this happen with HEAD last week. It's especially annoying because it loses all the folder settings like expiration and such which can be a real pain if you've set them on over 100 folders ;)
And I just noticed that during the last couple days, the contents of one of my folders has completely vanished, i.e. is no longer on both server or local cache. I can just assume that KMail falsely deleted the folders contents locally because of this error, and at a later sync falsely propagated that back to the server instead of redownloading folder contents. The folder contained about 1000 mails; thank God it was nothing really important.
CVS commit by burghard: - small cleanups - more debugging - and finally: fix the dimap cache eater. The noop jumped in between and returned success without my allowance. Please confirm. CCMAIL: 99278@bugs.kde.org M +17 -5 imap4.cc 1.205 --- kdepim/kioslaves/imap4/imap4.cc #1.204:1.205 @@ -1221,7 +1221,7 @@ void IMAP4Protocol::special (const QByteArray & aData) { + kdDebug(7116) << "IMAP4Protocol::special" << endl; if (!makeLogin()) return; - kdDebug(7116) << "IMAP4Protocol::special" << endl; QDataStream stream(aData, IO_ReadOnly); @@ -1250,4 +1250,10 @@ IMAP4Protocol::special (const QByteArray // NOOP imapCommand *cmd = doCommand(imapCommand::clientNoop()); + if (cmd->result () != "OK") + { + completeQueue.removeRef (cmd); + error (ERR_CONNECTION_BROKEN, myHost); + return; + } completeQueue.removeRef (cmd); finished(); @@ -1272,4 +1278,5 @@ IMAP4Protocol::special (const QByteArray if (cmd->result () != "OK") { + completeQueue.removeRef (cmd); error(ERR_SLAVE_DEFINED, i18n("Unsubscribe of folder %1 " "failed. The server returned: %2") @@ -1292,4 +1299,5 @@ IMAP4Protocol::special (const QByteArray if (cmd->result () != "OK") { + completeQueue.removeRef (cmd); error(ERR_SLAVE_DEFINED, i18n("Subscribe of folder %1 " "failed. The server returned: %2") @@ -1341,4 +1349,5 @@ IMAP4Protocol::special (const QByteArray if (cmd->result () != "OK") { + completeQueue.removeRef (cmd); error(ERR_COULD_NOT_WRITE, i18n("Changing the flags of message %1 " "failed.").arg(_url.prettyURL())); @@ -1352,4 +1361,5 @@ IMAP4Protocol::special (const QByteArray if (cmd->result () != "OK") { + completeQueue.removeRef (cmd); error(ERR_COULD_NOT_WRITE, i18n("Changing the flags of message %1 " "failed.").arg(_url.prettyURL())); @@ -1633,8 +1643,7 @@ void IMAP4Protocol::slave_status () { - kdDebug(7116) << "IMAP4::slave_status" << endl; -// KIO::TCPSlaveBase::slave_status(); - slaveStatus (myHost, !(getState () == ISTATE_NO)); -// slaveStatus(QString::null,false); + bool connected = (getState() != ISTATE_NO) && isConnectionValid(); + kdDebug(7116) << "IMAP4::slave_status " << connected << endl; + slaveStatus ( connected ? myHost : QString::null, connected ); } @@ -1839,4 +1848,5 @@ bool IMAP4Protocol::makeLogin () kdDebug(7116) << "IMAP4::makeLogin - checking login" << endl; bool alreadyConnected = getState() == ISTATE_CONNECT; + kdDebug(7116) << "IMAP4::makeLogin - alreadyConnected " << alreadyConnected << endl; if (alreadyConnected || connectToHost (myHost.latin1(), myPort)) { @@ -1983,4 +1993,6 @@ bool IMAP4Protocol::makeLogin () } completeQueue.removeRef (cmd); + } else { + kdDebug(7116) << "makeLogin - NO login" << endl; }
I assume this change did not make it into 3.4-rc1?
On Sunday 27 February 2005 00:29, Christian Hesse wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=99278 > > > > > ------- Additional Comments From mail earthworm de 2005-02-27 00:29 > ------- I assume this change did not make it into 3.4-rc1? Right. I'm even not sure if it will make it into 3.4 final as the release was tagged before. Coolo?
the release tag is just for the RC. Of course we will make sure fixes for grave bugs are going in the release
I think you can close this bug as fixed now Carsten. I haven't been able to reproduce it in HEAD even in cases where I used to be able to before.
Woops, didn't mean to do that :)
Öhm, fixed I assume?
I got this problem with KDE 3.4rc1 Debian packages (http://pkg-kde.alioth.debian.org/kde-3.4.0/). This is very annoying. Please reopen the bug. Thanks, Stéphane Magnenat
It is fixed after rc1 and the fix is included in the final 3.4.0 version, so no need to reopen unless you can reproduce this with version 3.4.0.