Bug#578434: cyrus: Changing Junk-Status to No-Junk (in Icedove3) let disappear mail and create hardlink

[Dan White]

On 20/04/10 15:06 +0200, Jakobus Schuerz wrote:
>Thank you for this hint.
>
>Here the Logging:
>
>This happened, when i set the Junkstate in "No-Junk" in the Junk-directory.
>
><1271768571<DONE
>>1271768571>267 OK Completed
><1271768571<268 uid store 8357 +FLAGS (NonJunk)
>>1271768571>* 2 FETCH (FLAGS (\Recent \Seen Junk NonJunk) UID 8357)
>268 OK Completed
><1271768571<269 uid store 8357 -FLAGS (Junk)
>>1271768571>* 2 FETCH (FLAGS (\Recent \Seen NonJunk) UID 8357)
>269 OK Completed
><1271768571<270 uid store 8357 -Flags (\Seen)
>>1271768571>* 2 FETCH (FLAGS (\Recent NonJunk) UID 8357)
>270 OK Completed
><1271768571<271 IDLE
>>1271768571>+ idling
><1271768571<DONE
>>1271768571>271 OK Completed
><1271768571<273 uid copy 8357 "INBOX"
>>1271768571>273 OK [COPYUID 1256304629 8357 27209] Completed

Copied to the INBOX, which should utilize a hard link if Cyrus determines
that it can. Those details should be hidden from the client though.

><1271768571<274 uid store 8357 +FLAGS (\Deleted \Seen)
>>1271768571>* 2 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 8357)
>274 OK Completed

Marked for deletion.

><1271768571<275 noop
>>1271768571>275 OK Completed
><1271768571<276 getquotaroot "INBOX/Junk"
>>1271768571>* QUOTAROOT INBOX/Junk
>276 OK Completed
><1271768571<277 UID fetch 8358:* (FLAGS)
>>1271768571>* 2 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 8357)
>277 OK Completed (0.000 sec)
><1271768571<278 IDLE
>>1271768571>+ idling

Closing the No-Junk mailbox should implicitly expunge the message (in the
No-Junk mailbox).

>This happened, when i changed into the INBOX, while the Mail disappears:
>
>==> 20098 <==
><1271768603<DONE
>>1271768603>* 1051 EXISTS
>* 7 RECENT
>140 OK Completed
><1271768603<141 noop
>>1271768603>141 OK Completed
><1271768603<142 getquotaroot "INBOX"
>>1271768603>* QUOTAROOT INBOX
>142 OK Completed
><1271768603<143 UID fetch 27209:* (FLAGS)
>>1271768603>* 1051 FETCH (FLAGS (\Recent NonJunk) UID 27209)
>143 OK Completed (0.000 sec)

There is probably some kind of caching involved here. Your client
is searching for any messages with UID 27209 or greater, and finds the new
message with that UID.

><1271768603<144 UID fetch 27209 (UID RFC822.SIZE FLAGS
>BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority
>X-Priority References Newsgroups In-Reply-To Content-Type x-spam-status
>x-spam-flag content-type x-bogosity)])
>>1271768603>* 1051 FETCH (FLAGS (\Recent NonJunk) UID 27209 RFC822.SIZE
>1913 BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority
>X-Priority References Newsgroups In-Reply-To Content-Type x-spam-status
>x-spam-flag content-type x-bogosity)] {321}
>Date: Sat, 7 Mar 2009 01:47:16 +0100
>From: Jakobus =?UTF-8?B?U2Now7xyeg==?= <xxxxx.xxxxx at xxxx.xx>
>To: jakob.schuerz at gmx.at, Jakobus =?UTF-8?B?U2Now7xyeg==?= (ICH)
> <xxxxxxxxxxxxx at xxxxxxxxx.xxxxxxxxx.xxx>
>Subject: Neuer Server TEST
>Message-ID: <20090307014716.2d595e1e at gmx.at>
>Content-Type: text/plain; charset=US-ASCII
>
>)
>144 OK Completed (0.000 sec)
><1271768604<145 uid store 27209 +Flags (\Seen \Deleted)
>>1271768604>* 1051 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 27209)
>145 OK Completed

The client marks the message for deletion, but I don't think it should be
from your stated expectation.

><1271768604<146 IDLE
>>1271768604>+ idling

And when you close the INBOX, the message should be unlinked or removed
as it's expunged.

-- 
Dan White