Severity raised to "critical" because you can loose messages.

So what do you suggest? That we keep uploading messages even if one couldn't be uploaded?

David Faure wrote:
> So what do you suggest? That we keep uploading messages even if one couldn't be uploaded?

Well, what I would like is an interupting dialog which presents the user 
the message (headers) in question together with the appropriate response 
from the IMAP server. The user should be able to move this "corrupt" 
message to another folder.

It might be important if the transfer continues afterwards. If you stop 
it, the user might start it again if he likes. (If you continue, the 
user could have the problem that many messages are not able to be 
uploaded, so he had to deal with all of them before KMail becomes "fully 
functional" again.)


If you can manage to collect the messages which could not be uploaded at 
the end of the upload process (while all other messages are already on 
the server) and allow moving at this point, it would be the better 
solution. However I think, this is much more difficult to implement.

BTW, while one of my folders was out of sync I made the mistake to move 
an "invalid" message to my trash folder. Unfortunatly the trash is 
pointing to an IMAP folder for my IMAP account. So I had one folder more 
out of sync. :-(
It's important to move the message in question into a local folder.

On Tuesday 11 May 2004 15:23, Andreas Gungl wrote:
> So I had one folder more out of sync. :-(
Unless I misunderstand this, note that in CVS HEAD you can use RMB / Check Mail For This Folder
to sync a single folder.

About the real issue here: yes I'd need such a faulty message to be able to fix this.

David Faure wrote:
>>So I had one folder more out of sync. :-(
> 
> Unless I misunderstand this, note that in CVS HEAD you can use RMB / Check Mail For This Folder
> to sync a single folder.

Ah, fine. I didn't know it also worked for dIMAP until now. :-)

> About the real issue here: yes I'd need such a faulty message to be able to fix this.

Sent in private mail. If you need additional information, please contact 
me again.

CVS commit by faure: 

Forward error message from server when ::put() fails
CCMAIL: 60384@bugs.kde.org, 81309@bugs.kde.org


  M +1 -1      imap4.cc   1.167


--- kdepim/kioslaves/imap4/imap4.cc  #1.166:1.167
@@ -801,5 +801,5 @@ IMAP4Protocol::put (const KURL & _url, i
         parseLoop ();
       if (cmd->result () != "OK")
-        error (ERR_COULD_NOT_WRITE, myHost);
+        error (ERR_SLAVE_DEFINED, cmd->resultInfo());
       else
       {

CVS commit by faure: 

Better error message when uploading a message fails, showing the From
and Subject of the message, so that it's possible to know which one it's about.
CCMAIL: 60384-done@bugs.kde.org, 81309@bugs.kde.org


  M +2 -5      cachedimapjob.cpp   1.50
  M +15 -0     imapaccountbase.cpp   1.72
  M +3 -0      imapaccountbase.h   1.42
  M +1 -1      imapjob.cpp   1.59


--- kdepim/kmail/cachedimapjob.cpp  #1.49:1.50
@@ -349,4 +349,5 @@ void CachedImapJob::slotPutNextMessage()
   }
   jd.data = mData;
+  jd.msgList.append( mMsg );
 
   mMsg->setTransferInProgress(true);
@@ -412,9 +413,5 @@ void CachedImapJob::slotPutMessageResult
 
   if ( job->error() ) {
-    // ### (*it).items isn't set... but showing a UID isn't really helpful, is it?
-    QString myError = "<p><b>" + i18n("Error while uploading message")
-      + "</b></p><p>" + i18n("Could not upload the message %1 on the server from folder %2 with URL %3.").arg((*it).items[0]).arg(mFolder->label()).arg((*it).htmlURL())
-      + "</p><p>" + i18n("This could be because you do not have permission to do this; the error message from the server communication is here:") + "</p>";
-    mAccount->handleJobError( job, myError );
+    mAccount->handlePutError( job, *it, mFolder->folder() );
     delete this;
     return;

--- kdepim/kmail/imapaccountbase.cpp  #1.71:1.72
@@ -630,4 +630,19 @@ namespace KMail {
 
   //-----------------------------------------------------------------------------
+  bool ImapAccountBase::handlePutError( KIO::Job* job, jobData& jd, KMFolder* folder )
+  {
+    Q_ASSERT( !jd.msgList.isEmpty() );
+    KMMessage* msg = jd.msgList.first();
+    // Use double-quotes around the subject to keep the sentence readable,
+    // but don't use double quotes around the sender since from() might return a double-quoted name already
+    const QString subject = msg->subject().isEmpty() ? i18n( "<unknown>" ) : QString("\"%1\"").arg( msg->subject() );
+    const QString from = msg->from().isEmpty() ? i18n( "<unknown>" ) : msg->from();
+    QString myError = "<p><b>" + i18n("Error while uploading message")
+      + "</b></p><p>" + i18n("Could not upload the message from %1 with subject %2 on the server. The destination folder was %3, which has the URL %4.").arg(from, subject, folder->label(), jd.htmlURL())
+      + "</p><p>" + i18n("The error message from the server communication is here:") + "</p>";
+    return handleJobError( job, myError );
+  }
+
+  //-----------------------------------------------------------------------------
   bool ImapAccountBase::handleError( int errorCode, const QString &errorMsg, KIO::Job* job, const QString& context, bool abortSync )
   {

--- kdepim/kmail/imapaccountbase.h  #1.41:1.42
@@ -340,4 +340,7 @@ namespace KMail {
     virtual bool handleError( int error, const QString &errorMsg, KIO::Job* job, const QString& context, bool abortSync = false );
 
+    /** Handle an error during KIO::put - helper method */
+    bool handlePutError( KIO::Job* job, jobData& jd, KMFolder* folder );
+
     virtual QString protocol() const;
     virtual unsigned short int defaultPort() const;

--- kdepim/kmail/imapjob.cpp  #1.58:1.59
@@ -443,5 +443,5 @@ void ImapJob::slotPutMessageResult( KIO:
   if (job->error())
   {
-    account->handleJobError( job, i18n("Error while uploading messages to the server.") );
+    account->handlePutError( job, *it, mDestFolder );
     return;
   } else {

> Syncing ends at the first "invalid" message.
Definitely not - you get a Continue/Cancel box, with CVS HEAD.

So unless I'm missing something this isn't a reason for mail loss, and with the now improved error handling I think this bug can be closed. Right?

On Wednesday 12 May 2004 10:06, you wrote:
> For a normal user it's not clear, what can he/she do to get back 
> to a normal (errorless, uninterupted) dIMAP sync. Having a not too small 
> amount of messages it is all but easy to find out (all of) the 
> problematic message(s) which make(s) the sync fail.
That's not the case anymore - now the dialog gives you the From and Subject of the message.

> I assume you want to tell me that "continue" will upload all but the 
> problematic message(s). Well, I found out that trying to upload about 
> 900 messages resulted in 6 uploaded messages. The 7th message seemed to 
> trigger the error. I definitly pressed "continue", but I believe this 
> means to continue with the next folder instead with the next message.
Oh... I didn't think about that. It's quite possible that it moves on to the next
step of the syncing process indeed.

Hmm, and this makes sense in cases like: you have 800 messages put into a readonly folder.
If you got 800 error dialog boxes it would be quite a problem......
But of course in such a case the user will simply abort and fix the problem 
(either get the permissions fixed or remove all the messages from there)
so maybe it makes sense to keep uploading messages after one message
couldn't be uploaded.... Hmm, cc'ing the BR to get more opinions.

On Mittwoch, 12. Mai 2004 10:14, David Faure wrote:
> On Wednesday 12 May 2004 10:06, you wrote:
> > For a normal user it's not clear, what can he/she do to get back
> > to a normal (errorless, uninterupted) dIMAP sync. Having a not too
> > small amount of messages it is all but easy to find out (all of) the
> > problematic message(s) which make(s) the sync fail.
>
> That's not the case anymore - now the dialog gives you the From and
> Subject of the message.

Sorry, I saw your commits after I had written my answer. It's fixed indeed.

What might be of additional help is to show also date and time of the 
message. I have often messages with the same (repeating) subject from the 
same account. In that case it's difficult to identify the message in 
question by only sender and subject. Another benefit would be to select the 
message in that folder, so that you can cancel the sync process and have 
the correct message handy for a move.
This is of course a wish and I better file a report for it if you won't be 
as fast as yesterday with the implementation.

> > I assume you want to tell me that "continue" will upload all but the
> > problematic message(s). Well, I found out that trying to upload about
> > 900 messages resulted in 6 uploaded messages. The 7th message seemed to
> > trigger the error. I definitly pressed "continue", but I believe this
> > means to continue with the next folder instead with the next message.
>
> Oh... I didn't think about that. It's quite possible that it moves on to
> the next step of the syncing process indeed.
>
> Hmm, and this makes sense in cases like: you have 800 messages put into a
> readonly folder. If you got 800 error dialog boxes it would be quite a
> problem...... But of course in such a case the user will simply abort and
> fix the problem (either get the permissions fixed or remove all the
> messages from there) so maybe it makes sense to keep uploading messages
> after one message couldn't be uploaded.... Hmm, cc'ing the BR to get more
> opinions.

Both possible scenarios seem to be usefull. Switching to the next folder 
means you can sync all but the problematic folder(s), but you loose the 
ability to upload as much messages as possible into a given folder after an 
error was found.
The other way round would allow you to continue or to cancel if there are to 
many problems in a folder. But you will have a problem to sync the other 
folders until you've managed to clean the folder in question.

In the moment I'm a bit undecided about what I would improve. Given that my 
wishes from above are implemented, I would prefer if KMail would try to 
complete the folder after a put error has occured.

Regards (and thanks to David for the quick fix)
Andreas

On Wednesday 12 May 2004 21:42, Andreas Gungl wrote:
> What might be of additional help is to show also date and time of the 
> message. I have often messages with the same (repeating) subject from the 
> same account. In that case it's difficult to identify the message in 
> question by only sender and subject.
Added.

> Another benefit would be to select the  
> message in that folder, so that you can cancel the sync process and have 
> the correct message handy for a move.
> This is of course a wish and I better file a report for it if you won't be 
> as fast as yesterday with the implementation.
Yes that sounds somewhat more complex. Just looked at it with Till, 
and it requires some framework changes (to know the kmmainwiget from there).
Added to TODO for later - leave this one open to remind me :)

> Both possible scenarios seem to be usefull. Switching to the next folder 
> means you can sync all but the problematic folder(s), but you loose the 
> ability to upload as much messages as possible into a given folder after an 
> error was found.
> The other way round would allow you to continue or to cancel if there are to 
> many problems in a folder. But you will have a problem to sync the other 
> folders until you've managed to clean the folder in question.
Not really, now that I made "check mail in this folder" work for cached imap too.
So I guess this speaks for the first solution.

> I would prefer if KMail would try to 
> complete the folder after a put error has occured.
I agree. Will do later.

CVS commit by lukas: 

backport CVS commit by faure: 

Forward error message from server when ::put() fails
CCMAIL: 60384@bugs.kde.org, 81309@bugs.kde.org


  M +2 -2      imap4.cc   1.140.2.7


--- kdebase/kioslave/imap4/imap4.cc  #1.140.2.6:1.140.2.7
@@ -756,5 +756,5 @@ IMAP4Protocol::put (const KURL & _url, i
         parseLoop ();
       if (cmd->result () != "OK")
-        error (ERR_COULD_NOT_WRITE, myHost);
+        error (ERR_SLAVE_DEFINED, cmd->resultInfo());
       else
       {

CVS commit by faure: 

Continue uploading messages after one message can't be uploaded (e.g.
due to invalid headers) and the user chooses "Continue".
CCMAIL: 81309@bugs.kde.org


  M +7 -2      cachedimapjob.cpp   1.51


--- kdepim/kmail/cachedimapjob.cpp  #1.50:1.51
@@ -413,6 +413,11 @@ void CachedImapJob::slotPutMessageResult
 
   if ( job->error() ) {
-    mAccount->handlePutError( job, *it, mFolder->folder() );
+    bool cont = mAccount->handlePutError( job, *it, mFolder->folder() );
+    if ( !cont ) {
     delete this;
+    } else {
+      mMsg = 0;
+      slotPutNextMessage();
+    }
     return;
   }

The bugs are fixed; retitling and setting to wishlist for the last item (although I don't plan to do it any time soon :/).

I'm closing this ticket because it has remained unchanged for ~8 years. Please reopen this ticket if the issue is current (KDE 4.8), and/or the remaining todo item is still actively pursued.