Moving nnimap articles failing with "has no process" error

Moving nnimap articles failing with "has no process" error

[John Sullivan]

I mark several messages with # to move, then do B m.

I get:

Opening TLS connection with `gnutls-cli --insecure -p imaps mail.fsf.org'...done
Opening TLS connection to `mail.fsf.org'...done
Opening nnimap server on fsf...done
Moving to nnimap+fsf:INBOX.SpamMisses: (54860 54862 54866 54870 54873)...
nnimap-send-command: Buffer *nnimap mail.fsf.org nil  *nntpd**<6> has no
process

Backtrace:

Debugger entered--Lisp error: (error "Buffer *nnimap mail.fsf.org nil  *nntpd**<7> has no process")
  process-send-string(nil "14357 UID STORE 54873 +FLAGS.SILENT (\\Deleted)\n")
  nnimap-send-command("UID STORE %s +FLAGS.SILENT (\\Deleted)" "54873")
  apply(nnimap-send-command ("UID STORE %s +FLAGS.SILENT (\\Deleted)" "54873"))
  nnimap-command("UID STORE %s +FLAGS.SILENT (\\Deleted)" "54873")
  nnimap-delete-article(54873)
  nnimap-request-move-article(54873 "INBOX.fsf" "local" (gnus-request-accept-article "nnimap+fsf:INBOX.SpamMisses" (quote nil) t t) t nil)
  gnus-request-move-article(54873 "nnimap+local:INBOX.fsf" "local" (gnus-request-accept-article "nnimap+fsf:INBOX.SpamMisses" (quote nil) t t) t nil)
  gnus-summary-move-article(nil)
  call-interactively(gnus-summary-move-article nil nil)

Yeah, I'm moving imap mail between servers. This used to work okay.

"Gnus v5.13" "24.0.50.1"

Here's the imap-log:

14000 NO Current box is selected READ-ONLY.
Return-path: NO Error in IMAP command received by server.
Envelope-to: NO Error in IMAP command received by server.
Received: NO Error in IMAP command received by server.
* NO Error in IMAP command received by server.
id NO Error in IMAP command received by server.
for NO Error in IMAP command received by server.
X-Spam-Checker-Version: NO Error in IMAP command received by server.
X-Spam-Level: NO Error in IMAP command received by server.
X-Spam-Status: NO Error in IMAP command received by server.
* BYE [ALERT] Fatal error: TOO MANY CONSECUTIVE PROTOCOL VIOLATIONS: 
- Peer has closed the GNUTLS connection

Process *nnimap* finished

Ideas? I tried closing all of the servers in the server buffer, and then
reopening them, but got the same error.

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

John Sullivan <john@wjsullivan.net> writes:

> I mark several messages with # to move, then do B m.
>

I forgot to mention that it moves one message successfully before it
errors.

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

This maybe seems to only happen when trying to move articles to a group
which has not been entered yet since upgrading. After entering the
target group, this move now seems to work..

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

John Sullivan <john@wjsullivan.net> writes:

> This maybe seems to only happen when trying to move articles to a group
> which has not been entered yet since upgrading. After entering the
> target group, this move now seems to work..

No, I was wrong about that, it's still happening. It moves one message
successfully and then fails.

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[Lars Magne Ingebrigtsen]

John Sullivan <john@wjsullivan.net> writes:

> 14000 NO Current box is selected READ-ONLY.

This has to mean that the mailbox was selected with EXAMINE instead of
SELECT.  But I don't quite understand how -- I've gone over all the
instances in nnimap where it issues EXAMINE, and they all mark the group
as non-selected, so.  Hm.

Or does this mean that the server refuses to accept APPEND to a mail box
if it has been EXAMINEd?  I mean, you don't have to SELECT a mailbox
before APPENDing to it...

Oh, now I see the problem.  Fixed and pushed.

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

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Sullivan <john@wjsullivan.net> writes:
>
>> 14000 NO Current box is selected READ-ONLY.
>
> This has to mean that the mailbox was selected with EXAMINE instead of
> SELECT.  But I don't quite understand how -- I've gone over all the
> instances in nnimap where it issues EXAMINE, and they all mark the group
> as non-selected, so.  Hm.
>
> Or does this mean that the server refuses to accept APPEND to a mail box
> if it has been EXAMINEd?  I mean, you don't have to SELECT a mailbox
> before APPENDing to it...
>
> Oh, now I see the problem.  Fixed and pushed.

I've updated, but still seem to be having the problem in the same way.
Here's the imap log now:

10:41:57 296 UID FETCH 56712 BODY.PEEK[]
10:41:57 297 APPEND "INBOX.SpamMisses" {4053}
10:41:57 298 EXAMINE "INBOX.SpamMisses"
10:41:57 299 UID SEARCH HEADER Message-Id "<rt-3.4.5-2735-1289924545-1966.636600-21-0@rt.gnu.org>"
10:41:58 300 UID STORE 56712 +FLAGS.SILENT (\Deleted)
10:41:58 301 UID EXPUNGE 56712
10:41:58 302 UID FETCH 56649 BODY.PEEK[]
10:41:58 303 APPEND "INBOX.SpamMisses" {3824}
10:41:58 304 EXAMINE "INBOX.SpamMisses"
10:41:58 305 UID SEARCH HEADER Message-Id "<rt-3.4.5-2735-1289888599-1690.636443-21-0@rt.gnu.org>"
10:41:58 306 UID STORE 56649 +FLAGS.SILENT (\Deleted)

It dies with the error:

Moving to nnimap+fsf:INBOX.SpamMisses: (56712 56649)...
nnimap-send-command: Buffer *nnimap mail.fsf.org nil  *nntpd**<2> has no process

after successfully moving the first of 2 marked messages.

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

John Sullivan <john@wjsullivan.net> writes:

> John Sullivan <john@wjsullivan.net> writes:
>
>> I mark several messages with # to move, then do B m.
>>
>
> I forgot to mention that it moves one message successfully before it
> errors.

The plot thickens -- the messages aren't actually being moved at all,
even when there is no error.

They are initially marked with a G in the Summary buffer, when moved one
at a time, but I've just discovered that after re-entering the group,
they are still lurking there, now marked with O.

So, moving mail from one nnimap server to another seems to not be
working.

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[Lars Magne Ingebrigtsen]

John Sullivan <john@wjsullivan.net> writes:

> I've updated, but still seem to be having the problem in the same way.

It seems like the fix went AWOL somewhere.  I've now made sure that the
group is deselected before APPENDing to it, since EXAMINE opens a group
read-only, and that makes some servers refuse to APPEND to it.

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

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Sullivan <john@wjsullivan.net> writes:
>
>> I've updated, but still seem to be having the problem in the same way.
>
> It seems like the fix went AWOL somewhere.  I've now made sure that the
> group is deselected before APPENDing to it, since EXAMINE opens a group
> read-only, and that makes some servers refuse to APPEND to it.

Updated, and verified that it works for me now. Thanks!

-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[John Sullivan]

John Sullivan <john@wjsullivan.net> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> John Sullivan <john@wjsullivan.net> writes:
>>
>>> I've updated, but still seem to be having the problem in the same way.
>>
>> It seems like the fix went AWOL somewhere.  I've now made sure that the
>> group is deselected before APPENDing to it, since EXAMINE opens a group
>> read-only, and that makes some servers refuse to APPEND to it.
>
> Updated, and verified that it works for me now. Thanks!

Sorry to keep going back and forth on this, but it's not actually
working. There is no error, but the message also isn't being moved. I
end up with two copies of the message, one marked O in the original
group, and one unread in the new group. Below is log data surrounding a
move of a message from INBOX.fsf to INBOX.SpamMisses, which are on two
different servers.

09:51:08 1049 SELECT "INBOX.fsf"
09:51:08 1050 SELECT "INBOX.fsf"
09:51:08 1051 UID FETCH 1:* FLAGS
09:51:10 1052 UID FETCH 4,8,21,24:25,293,295,1811,2069,2115,2130,7268,16952,17509,23988,29290,29777,29799,32244,32357,34594,34719,39324,46495,48542,49422,52582,53498,53979,54452,54539,54895,56877,58033,58040,58075,58174,58180,58240,58784,58921,58943,59065,59148,59167,59172,59272,59284,59300,59570:59571,59618,59630,59651,59661,59680,59735,59778,59788,59798,59829,59831,59920,59924,59979,59981,59988,60012,60020,60023,60071,60082,60132,60142,60144,60172,60185,60195,60230,60236,60244,60246,60251,60259,60261:60263,60266,60268:60269,60274,60276,60292,60399,60401,60422,60424,60432:60435,60439,60454,60464,60486:60487,60586,60603,60607,60638,60643,60646,60649,60651:60654,60660:60662,60664,60666,60673:60679,60681:60684,60686,60688:60706 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject 
 From Date Message-Id References In-Reply-To Xref To Newsgroups)])
09:51:12 1053 UID FETCH 60662 BODY.PEEK[]
09:51:14 1054 UID FETCH 60705 BODY.PEEK[]
09:51:18 1055 UID FETCH 59680 BODY.PEEK[]
09:51:25 1056 UID FETCH 59148 BODY.PEEK[]
09:51:29 1057 UID FETCH 59167 BODY.PEEK[]
09:51:33 1058 UID FETCH 59284 BODY.PEEK[]
09:51:52 1059 UID FETCH 59570 BODY.PEEK[]
09:52:15 1060 UID FETCH 59300 BODY.PEEK[]
09:52:25 1061 NOOP
09:52:25 1062 NOOP
09:52:25 1063 NOOP
09:56:55 1064 EXAMINE DOES.NOT.EXIST
09:56:55 1065 APPEND "INBOX.fsf" {1752}
09:56:55 1066 SELECT "INBOX.fsf"
09:56:55 1067 UID FETCH 1:* FLAGS
09:56:59 1068 UID FETCH 59920 BODY.PEEK[]
09:57:14 1069 UID FETCH 60660 BODY.PEEK[]
09:57:50 1070 UID FETCH 60646 BODY.PEEK[]
09:58:01 1071 UID FETCH 60401 BODY.PEEK[]
09:58:33 1072 UID FETCH 60432 BODY.PEEK[]
09:58:53 1073 UID FETCH 60433 BODY.PEEK[]
09:58:55 1074 UID FETCH 60603 BODY.PEEK[]
09:59:29 1075 UID FETCH 60487 BODY.PEEK[]
09:59:33 1076 UID FETCH 60649 BODY.PEEK[]
09:59:48 1077 UID FETCH 60020 BODY.PEEK[]
10:03:06 1078 UID FETCH 60666 BODY.PEEK[]
10:07:25 1079 NOOP
10:07:25 1080 NOOP
10:07:25 1081 NOOP
10:09:32 1082 EXAMINE DOES.NOT.EXIST
10:09:32 1083 APPEND "INBOX.fsf" {1106}
10:09:32 1084 SELECT "INBOX.fsf"
10:09:32 1085 UID FETCH 1:* FLAGS
10:09:40 1086 UID FETCH 60259 BODY.PEEK[]
10:09:42 1087 UID FETCH 60261 BODY.PEEK[]
10:09:57 1088 UID FETCH 60263 BODY.PEEK[]
10:10:03 1089 UID FETCH 60268 BODY.PEEK[]
10:10:06 1090 UID FETCH 60262 BODY.PEEK[]
10:10:09 1091 UID FETCH 60269 BODY.PEEK[]
10:10:20 1092 UID FETCH 60700 BODY.PEEK[]
10:10:32 1093 UID FETCH 60703 BODY.PEEK[]
10:10:33 1094 UID FETCH 60704 BODY.PEEK[]
10:10:35 1095 UID FETCH 60706 BODY.PEEK[]
10:10:47 1096 UID FETCH 60681 BODY.PEEK[]
10:10:57 1097 UID FETCH 60651 BODY.PEEK[]
10:11:03 1098 UID FETCH 60679 BODY.PEEK[]
10:11:46 1099 EXAMINE DOES.NOT.EXIST
10:11:46 1100 APPEND "INBOX.fsf" {1291}
10:11:46 1101 SELECT "INBOX.fsf"
10:11:46 1102 UID FETCH 1:* FLAGS
10:11:51 1103 UID FETCH 60638 BODY.PEEK[]
10:11:58 1104 UID FETCH 60677 BODY.PEEK[]
10:12:03 1105 UID FETCH 60693 BODY.PEEK[]
10:19:10 1106 UID FETCH 60454 BODY.PEEK[]
10:19:47 1107 EXAMINE DOES.NOT.EXIST
10:19:48 1108 APPEND "INBOX.fsf" {1271}
10:19:48 1109 SELECT "INBOX.fsf"
10:19:48 1110 UID FETCH 1:* FLAGS
10:19:50 1111 UID FETCH 60676 BODY.PEEK[]
10:21:49 1112 EXAMINE DOES.NOT.EXIST
10:21:49 1113 APPEND "INBOX.fsf" {1303}
10:21:49 1114 SELECT "INBOX.fsf"
10:21:49 1115 UID FETCH 1:* FLAGS
10:21:52 1116 UID FETCH 60691 BODY.PEEK[]
10:22:25 1117 NOOP
10:22:25 1118 NOOP
10:22:25 1119 NOOP
10:23:47 1120 UID FETCH 60688 BODY.PEEK[]
10:23:49 1121 UID FETCH 59798 BODY.PEEK[]
10:23:53 1122 UID FETCH 59661 BODY.PEEK[]
10:23:54 1123 UID FETCH 60071 BODY.PEEK[]
10:24:06 1124 UID FETCH 60701 BODY.PEEK[]
10:24:21 1125 UID FETCH 60701 BODY.PEEK[]
10:24:21 1126 APPEND "INBOX.SpamMisses" {5486}
10:24:23 1127 UID STORE 60701 +FLAGS.SILENT (\Deleted)
10:24:23 1128 UID EXPUNGE 60701
10:24:23 1129 SELECT "INBOX.SpamMisses"
10:24:23 1130 UID STORE 21971 +FLAGS.SILENT (\Seen)
10:24:24 1131 SELECT "INBOX.SpamMisses"
10:24:24 1132 UID FETCH 1:* FLAGS
10:24:37 1133 UID STORE 59148,59167,59284,59300,59570,59661,59680,59798,60071,60259,60261:60263,60268:60269,60399,60401,60432:60433,60454,60487,60603,60638,60646,60649,60651,60654,60660,60662,60666,60676:60677,60679,60681:60684,60688,60691:60693,60695:60697,60700:60701,60703:60706,60708:60712 +FLAGS.SILENT (\Seen)
10:24:37 1134 UID STORE 59148,60454,60666,60676,60679 +FLAGS.SILENT
(\Answered)


-- 
John Sullivan
Emacs Planner Maintainer
http://wjsullivan.net/PlannerMode.html

Re: Moving nnimap articles failing with "has no process" error

[Lars Magne Ingebrigtsen]

John Sullivan <john@wjsullivan.net> writes:

> Sorry to keep going back and forth on this, but it's not actually
> working. There is no error, but the message also isn't being moved. I
> end up with two copies of the message, one marked O in the original
> group, and one unread in the new group. Below is log data surrounding a
> move of a message from INBOX.fsf to INBOX.SpamMisses, which are on two
> different servers.

Hm...

> 10:19:47 1107 EXAMINE DOES.NOT.EXIST
> 10:19:48 1108 APPEND "INBOX.fsf" {1271}
> 10:19:48 1109 SELECT "INBOX.fsf"

So when appending to INBOX.fsf, it unselects first.

> 10:24:21 1125 UID FETCH 60701 BODY.PEEK[]
> 10:24:21 1126 APPEND "INBOX.SpamMisses" {5486}

But not here...  but that makes sense, since it hadn't selected that
group.

> 10:24:23 1127 UID STORE 60701 +FLAGS.SILENT (\Deleted)
> 10:24:23 1128 UID EXPUNGE 60701
> 10:24:23 1129 SELECT "INBOX.SpamMisses"
> 10:24:23 1130 UID STORE 21971 +FLAGS.SILENT (\Seen)

And it set the \Seen flag on the article after it moved it, which means
that it thinks that it didn't fail.

So based on this log, it really looks like it should have worked...

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