Incoming IMAP split problem

Incoming IMAP split problem

[Michael Welsh Duggan]

Here's a portion of an IMAP split log that looks fishy:

11:18:36 882 SELECT "INBOX"
11:18:36 883 UID FETCH 1:* FLAGS
11:18:36 884 UID FETCH 25439:25440 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
11:18:36 885 UID COPY 25440 "INBOX/sei"
11:18:36 886 UID STORE 25439 +FLAGS.SILENT (\Deleted)
11:18:36 887 EXPUNGE

Why is it copying 25440 (correctly), and then deleting 25439 (which I
didn't see)?  Am I losing mail?

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Incoming IMAP split problem

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Here's a portion of an IMAP split log that looks fishy:
>
> 11:18:36 882 SELECT "INBOX"
> 11:18:36 883 UID FETCH 1:* FLAGS
> 11:18:36 884 UID FETCH 25439:25440 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 11:18:36 885 UID COPY 25440 "INBOX/sei"
> 11:18:36 886 UID STORE 25439 +FLAGS.SILENT (\Deleted)
> 11:18:36 887 EXPUNGE
>
> Why is it copying 25440 (correctly), and then deleting 25439 (which I
> didn't see)?  Am I losing mail?

Here's another example.  In this case I was able to verify that the two
deleted messages were properly deleted (split to 'junk).

11:28:36 976 SELECT "INBOX"
11:28:36 977 UID FETCH 1:* FLAGS
11:28:36 978 UID FETCH 25441:25444 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
11:28:36 979 UID COPY 25441:25442 "INBOX/misc"
11:28:37 980 UID STORE 25443:25444 +FLAGS.SILENT (\Deleted)
11:28:37 981 EXPUNGE

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

>> Here's a portion of an IMAP split log that looks fishy:
>>
>> 11:18:36 882 SELECT "INBOX"
>> 11:18:36 883 UID FETCH 1:* FLAGS
>> 11:18:36 884 UID FETCH 25439:25440 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
>> 11:18:36 885 UID COPY 25440 "INBOX/sei"
>> 11:18:36 886 UID STORE 25439 +FLAGS.SILENT (\Deleted)
>> 11:18:36 887 EXPUNGE
>>
>> Why is it copying 25440 (correctly), and then deleting 25439 (which I
>> didn't see)?  Am I losing mail?

If you have a 'junk split, then than means that Gnus will just delete
the message, and I think that's what you're seeing.  So, yes, you're
losing mail.  The 'junk mail.

> Here's another example.  In this case I was able to verify that the two
> deleted messages were properly deleted (split to 'junk).
>
> 11:28:36 976 SELECT "INBOX"
> 11:28:36 977 UID FETCH 1:* FLAGS
> 11:28:36 978 UID FETCH 25441:25444 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 11:28:36 979 UID COPY 25441:25442 "INBOX/misc"
> 11:28:37 980 UID STORE 25443:25444 +FLAGS.SILENT (\Deleted)
> 11:28:37 981 EXPUNGE

Looks like the same thing here?  25443:25444 are 'junk articles?  But I
don't understand why 25441:25442 aren't deleted, too.  I mean, they've
been split to other mailboxes, so they should be removed from INBOX,
shouldn't they?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Emilio Jesús Gallego Arias]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Here's another example.  In this case I was able to verify that the two
>> deleted messages were properly deleted (split to 'junk).
>>
>> 11:28:36 976 SELECT "INBOX"
>> 11:28:36 977 UID FETCH 1:* FLAGS
>> 11:28:36 978 UID FETCH 25441:25444 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
>> 11:28:36 979 UID COPY 25441:25442 "INBOX/misc"
>> 11:28:37 980 UID STORE 25443:25444 +FLAGS.SILENT (\Deleted)
>> 11:28:37 981 EXPUNGE
>
> Looks like the same thing here?  25443:25444 are 'junk articles?  But I
> don't understand why 25441:25442 aren't deleted, too.  I mean, they've
> been split to other mailboxes, so they should be removed from INBOX,
> shouldn't they?

I'm getting a but where some mail is split but not deleted from
INBOX. Looking at imap log seems like the code after the COPY
(nnimap-mark-and-expunge-incoming) is never executed.

However I had no luck to see what happened in the *nnimap server*
buffer, when I switch to it already has newer commands than the ones I
need to look into.

The bug is hard to reproduce for me, I'll try.

Regards,
Emilio

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

egallego@babel.ls.fi.upm.es (Emilio Jesús Gallego Arias) writes:

> I'm getting a but where some mail is split but not deleted from
> INBOX. Looking at imap log seems like the code after the COPY
> (nnimap-mark-and-expunge-incoming) is never executed.

Looking at the code, it seems like the only way that code isn't executed
is if `sequences' is nil.  But `sequences' is never nil if a COPY has
been done.

It's a head-scratcher.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's a head-scratcher.

Aha!  If `nnimap-parse-copied-articles' returns nil (which should be
possible if there's anything strange in the responses), then the
deletion/expunging of the copied messages won't happen.  I think that
must be it, and it'd be interesting to see the value of `sequences' in
that function in the instances when it fails.

A debug-on-entry on that function should give you that info.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Here's a portion of an IMAP split log that looks fishy:
>
> 11:18:36 882 SELECT "INBOX"
> 11:18:36 883 UID FETCH 1:* FLAGS
> 11:18:36 884 UID FETCH 25439:25440 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 11:18:36 885 UID COPY 25440 "INBOX/sei"
> 11:18:36 886 UID STORE 25439 +FLAGS.SILENT (\Deleted)
> 11:18:36 887 EXPUNGE
>
> Why is it copying 25440 (correctly), and then deleting 25439 (which I
> didn't see)?  Am I losing mail?

Another case of nnimap split problem: copy but not deleted.

Since several weeks[1], I have some mail duplicated, at random times.

I set imap-log to t and found something interessting:

#v+
08:10:00 128662 LIST "" "*"
08:10:00 128663 SELECT "INBOX"
08:10:00 128664 UID FETCH 1:* FLAGS
08:10:00 128665 UID FETCH 76846 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
08:10:00 128666 UID COPY 76846 "baby-gnu.org.dehennin"
08:10:00 128667 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
08:10:00 128668 EXAMINE "linux.netfilter.user" (QRESYNC (1176563164 3))
[...] bunch of EXAMINE of all my groups
08:15:00 128754 LIST "" "*"
08:15:00 128755 SELECT "INBOX"
08:15:00 128756 UID FETCH 1:* FLAGS
08:15:00 128757 UID FETCH 76846 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
08:15:00 128758 UID COPY 76846 "baby-gnu.org.dehennin"
08:15:00 128759 UID STORE 76846 +FLAGS.SILENT (\Deleted)
08:15:00 128760 UID EXPUNGE 76846
08:15:00 128761 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
#v-

The mail is splited twice.

Maybe the run of the daemon interfer somewhere?

Any idea?


Footnotes: 
[1]  I do not remember when it starts

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Incoming IMAP split problem

[Emilio Jesús Gallego Arias]

Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:

> Another case of nnimap split problem: copy but not deleted.
>
> I set imap-log to t and found something interessting:
>
> #v+
> 08:10:00 128662 LIST "" "*"
> [snip]
> 08:15:00 128761 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
> #v-

That's exactly what I was seeing but it is difficult to duplicate. Lars
suggested stepping through the function, but I've modified it in order
to log the interesting values:


diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 74ef756..1ffe5ad 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1794,6 +1794,7 @@ textual parts.")
              (nnimap-wait-for-response (caar sequences))
              ;; And then mark the successful copy actions as deleted,
              ;; and possibly expunge them.
+             (message "NNIMAP SPLIT DEBUG %s %s" (nnimap-parse-copied-articles sequences) sequences)
              (nnimap-mark-and-expunge-incoming
               (nnimap-parse-copied-articles sequences)))
             (nnimap-mark-and-expunge-incoming junk-articles)))))))

Could you apply the patch and post the message when splitting goes wrong?

I guess posting also the contents of the response for the COPY command
would be useful.

Regards,
Emilio

Re: Incoming IMAP split problem

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]

egallego@babel.ls.fi.upm.es (Emilio Jesús Gallego Arias) writes:


[...]

> diff --git a/lisp/nnimap.el b/lisp/nnimap.el
> index 74ef756..1ffe5ad 100644
> --- a/lisp/nnimap.el
> +++ b/lisp/nnimap.el

[...]


Here is the patch I use:

#v+
diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 4e220bc..c4d9d20 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1794,6 +1794,7 @@ textual parts.")
 	      (nnimap-wait-for-response (caar sequences))
 	      ;; And then mark the successful copy actions as deleted,
 	      ;; and possibly expunge them.
+              (nnimap-log-command (format "NNIMAP SPLIT DEBUG %s %s\n" (nnimap-parse-copied-articles sequences) sequences))
 	      (nnimap-mark-and-expunge-incoming
 	       (nnimap-parse-copied-articles sequences)))
             (nnimap-mark-and-expunge-incoming junk-articles)))))))
#v-


Here is the output in *imap log*:

#v+ One working
17:19:04 165506 LIST "" "*"
17:19:04 165507 SELECT "INBOX"
17:19:04 165508 UID FETCH 1:* FLAGS
17:19:04 165509 UID FETCH 76938 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
17:19:04 165510 UID COPY 76938 "baby-gnu.org.dad"
17:19:04 NNIMAP SPLIT DEBUG (76938) ((165510 (76938)))
17:19:04 165511 UID STORE 76938 +FLAGS.SILENT (\Deleted)
17:19:04 165512 UID EXPUNGE 76938
#v-

#v+ One not working
17:45:00 166064 LIST "" "*"
17:45:00 166065 SELECT "INBOX"
17:45:00 166066 UID FETCH 1:* FLAGS
17:45:00 166067 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
17:45:00 166068 UID COPY 76939 "baby-gnu.org.dehennin"
17:45:00 NNIMAP SPLIT DEBUG nil ((166068 (76939)))
[...]
17:45:00 166064 LIST "" "*"
17:45:00 166065 SELECT "INBOX"
17:45:00 166066 UID FETCH 1:* FLAGS
17:45:00 166067 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
17:45:00 166068 UID COPY 76939 "baby-gnu.org.dehennin"
17:45:00 NNIMAP SPLIT DEBUG nil ((166068 (76939)))
17:45:00 166069 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
[...]
17:46:44 166156 LIST "" "*"
17:46:44 166157 SELECT "INBOX"
17:46:44 166158 UID FETCH 1:* FLAGS
17:46:44 166159 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
17:46:44 166160 UID COPY 76939 "baby-gnu.org.dehennin"
17:46:44 NNIMAP SPLIT DEBUG nil ((166160 (76939)))
17:46:44 166161 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
[...]
17:50:00 166251 LIST "" "*"
17:50:00 166252 SELECT "INBOX"
17:50:00 166253 UID FETCH 1:* FLAGS
17:50:00 166254 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
17:50:00 166255 UID COPY 76939 "baby-gnu.org.dehennin"
17:50:00 NNIMAP SPLIT DEBUG (76939) ((166255 (76939)))
17:50:00 166256 UID STORE 76939 +FLAGS.SILENT (\Deleted)
17:50:00 166257 UID EXPUNGE 76939
17:50:00 166258 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
#v-

> I guess posting also the contents of the response for the COPY command
> would be useful.

I can test if you have a patch, off for beer now ;-)

Regards.

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Incoming IMAP split problem

[Emilio Jesús Gallego Arias]

Really useful info Daniel

Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:

> #v+ One working
> 17:19:04 165506 LIST "" "*"
> 17:19:04 165507 SELECT "INBOX"
> 17:19:04 165508 UID FETCH 1:* FLAGS
> 17:19:04 165509 UID FETCH 76938 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 17:19:04 165510 UID COPY 76938 "baby-gnu.org.dad"
> 17:19:04 NNIMAP SPLIT DEBUG (76938) ((165510 (76938)))
> 17:19:04 165511 UID STORE 76938 +FLAGS.SILENT (\Deleted)
> 17:19:04 165512 UID EXPUNGE 76938
> #v-
>
> #v+ One not working
> 17:45:00 166064 LIST "" "*"
> 17:45:00 166065 SELECT "INBOX"
> 17:45:00 166066 UID FETCH 1:* FLAGS
> 17:45:00 166067 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 17:45:00 166068 UID COPY 76939 "baby-gnu.org.dehennin"
> 17:45:00 NNIMAP SPLIT DEBUG nil ((166068 (76939)))

So indeed nnimap-parse-copied-articles returns nil. I'll add some debug
info to that function.

>> I guess posting also the contents of the response for the COPY command
>> would be useful.
>
> I can test if you have a patch, off for beer now ;-)

I'll cook a patch.

Regards,
Emilio

Re: Incoming IMAP split problem

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> It's a head-scratcher.
>
> Aha!  If `nnimap-parse-copied-articles' returns nil (which should be
> possible if there's anything strange in the responses), then the
> deletion/expunging of the copied messages won't happen.  I think that
> must be it, and it'd be interesting to see the value of `sequences' in
> that function in the instances when it fails.
>
> A debug-on-entry on that function should give you that info.

Unfortunately, I have not been able to trigger this while the
debug-on-entry is enabled.  (Although I can, periodically, without.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:

> 17:45:00 166067 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
> 17:45:00 166068 UID COPY 76939 "baby-gnu.org.dehennin"
> 17:45:00 NNIMAP SPLIT DEBUG nil ((166068 (76939)))

Interesting.  This is what's failing.

Could you add the following patch, too?  It will add the contents of the
buffer to the log, too, so that we can see what's failing when trying to
parse the COPY results.

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 9c93ee8..645d85a 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1821,6 +1821,7 @@ textual parts.")
       (nnimap-wait-for-response sequence))))
 
 (defun nnimap-parse-copied-articles (sequences)
+  (nnimap-log-command "IMAP DEBUG %s %s" sequences (buffer-string))
   (let (sequence copied range)
     (goto-char (point-min))
     (while (re-search-forward "^\\([0-9]+\\) OK " nil t)


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:
>
>> 17:45:00 166067 UID FETCH 76939 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
>> 17:45:00 166068 UID COPY 76939 "baby-gnu.org.dehennin"
>> 17:45:00 NNIMAP SPLIT DEBUG nil ((166068 (76939)))
>
> Interesting.  This is what's failing.
>
> Could you add the following patch, too?  It will add the contents of the
> buffer to the log, too, so that we can see what's failing when trying to
> parse the COPY results.
>
> diff --git a/lisp/nnimap.el b/lisp/nnimap.el
> index 9c93ee8..645d85a 100644
> --- a/lisp/nnimap.el
> +++ b/lisp/nnimap.el
> @@ -1821,6 +1821,7 @@ textual parts.")
>        (nnimap-wait-for-response sequence))))
>  
>  (defun nnimap-parse-copied-articles (sequences)
> +  (nnimap-log-command "IMAP DEBUG %s %s" sequences (buffer-string))
>    (let (sequence copied range)
>      (goto-char (point-min))
>      (while (re-search-forward "^\\([0-9]+\\) OK " nil t)

I had to change the log command to include format and a newline, but
here's the output, given a single message in the INBOX:

18:50:37 196790 SELECT "INBOX"
18:50:37 196791 UID FETCH 1:* FLAGS
18:50:37 196792 UID FETCH 177059 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
18:50:37 196793 UID COPY 177059 "mail.misc"
18:50:37 IMAP DEBUG ((196793 (177059))) 196793 OK
18:50:37 NNIMAP SPLIT DEBUG nil ((196793 (177059)))
18:50:37 IMAP DEBUG ((196793 (177059))) 196793 OK

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> 18:50:37 IMAP DEBUG ((196793 (177059))) 196793 OK

Ah.  I understand what the problem is now, and it should be fixed in No
Gnus now.  Could you check whether this actually fixes the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> 18:50:37 IMAP DEBUG ((196793 (177059))) 196793 OK
>
> Ah.  I understand what the problem is now, and it should be fixed in No
> Gnus now.  Could you check whether this actually fixes the problem?

In a simple test, it does appear to.  I'll let you know if I see any
regressions later on.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Incoming IMAP split problem

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> 18:50:37 IMAP DEBUG ((196793 (177059))) 196793 OK
>
> Ah.  I understand what the problem is now, and it should be fixed in No
> Gnus now.  Could you check whether this actually fixes the problem?

Still have issue here:

#v+
19:15:00 194870 LIST "" "*"
19:15:00 194871 SELECT "INBOX"
19:15:00 194872 UID FETCH 1:* FLAGS
19:15:00 194873 UID FETCH 76996 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
19:15:00 194874 UID COPY 76996 "debian.bugs"
19:15:00 IMAP DEBUG ((194874 (76996))) 194874 O
19:15:00 NNIMAP SPLIT DEBUG nil ((194874 (76996)))
19:15:00 IMAP DEBUG ((194874 (76996))) 194874 O
19:15:00 194875 EXAMINE "baby-gnu.org.cf" (QRESYNC (1236917076 2))
#v-

Regards.

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Incoming IMAP split problem

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:

[...]

> Still have issue here:

[...]

Seems the output of copy is not always fully parsed:

#v+ Full outpu one
23:15:00 1994 LIST "" "*"
23:15:00 1995 SELECT "INBOX"
23:15:00 1996 UID FETCH 1:* FLAGS
23:15:00 1997 UID FETCH 77002 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
23:15:00 1998 UID COPY 77002 "debian.devel.announce"
23:15:00 IMAP DEBUG ((1998 (77002))) 1998 OK [COPYUID 1219435962 77002 319] Copy completed.

23:15:00 NNIMAP SPLIT DEBUG (77002) ((1998 (77002)))
23:15:00 IMAP DEBUG ((1998 (77002))) 1998 OK [COPYUID 1219435962 77002 319] Copy completed.

23:15:00 1999 UID STORE 77002 +FLAGS.SILENT (\Deleted)
23:15:00 2000 UID EXPUNGE 77002
#v-

#v+ Truncated output
23:05:00 1808 LIST "" "*"
23:05:00 1809 SELECT "INBOX"
23:05:00 1810 UID FETCH 1:* FLAGS
23:05:00 1811 UID FETCH 77001 (UID BODY.PEEK[HEADER] BODY.PEEK[1])
23:05:00 1812 UID COPY 77001 "gnu.cfengine.help"
23:05:00 IMAP DEBUG ((1812 (77001))) 1812 OK [COPYUID 118928
23:05:00 NNIMAP SPLIT DEBUG (77001) ((1812 (77001)))
23:05:00 IMAP DEBUG ((1812 (77001))) 1812 OK [COPYUID 118928
23:05:00 1813 UID STORE 77001 +FLAGS.SILENT (\Deleted)
23:05:00 1814 UID EXPUNGE 77001
#v-

Regards.
-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Incoming IMAP split problem

[Lars Ingebrigtsen]

Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:

> 19:15:00 IMAP DEBUG ((194874 (76996))) 194874 O

Ah!  Now I understand what the problem is.  `nnimap-wait-for-response'
wouldn't wait until the entire line had arrived -- if there was only a
single line in the process buffer.

This should now be fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Incoming IMAP split problem

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ah!  Now I understand what the problem is.  `nnimap-wait-for-response'
> wouldn't wait until the entire line had arrived -- if there was only a
> single line in the process buffer.
>
> This should now be fixed.

Seems it is, thanks.
-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]