Quoting from Eric S. Raymond's mail on Thu, Dec 27, 2001 at 06:20:13PM -0500:
Henrique de Moraes Holschuh <hmh(_at_)debian(_dot_)org>:
On Tue, 25 Dec 2001, Byrial Jensen wrote:
Static variables in C-programs which are not explicitly initialized
are initialized to 0 when the program is started. See for example
I thought as much. Still, see the comments about daemon mode and polling
cycles elsewhere in this thread... Initializing them in the declaration is
not needed, but it does give a hint that they are expected to start at zero,
and [should be] reset after (as opposed as to being initialized at the start
of every cycle).
Yes, the hint is why I took this patch.
Ok.
However, now one more problem occurs in the same case of failed
EXPUNGE.
If the transaction breaks between the STORE and EXPUNGE commands, then
a) for fetchall, the same mail is downloaded on the next poll.
b) for 'no fetchall', things get slightly weird!
If there are three mails, the mail status flags are:
1 Seen Deleted (This is because of previous failed EXPUNGE)
2 U U
3 U U
4 U U
The transaction goes as
number expunged (number-expunged) deletions
Start of second poll - 0 - 0
[ first mail is seen, so second mail is fetched ]
FETCH 2 0 2 0
STORE 2 0 2 1
EXPUNGE 2 1 1 0
[ first and second mails expunged here ]
FETCH 3 1 2 0
^
(this should be one)
If there are more than 3 mails in the INBOX, the wrong mail would be
downloaded, possibly with the message that mail was not of the
expected length!
If you check your INBOX through another program and set the delete
flags for arbitrary mails, but do not expunge, things can get haywire.
Example:
1 Seen Deleted
2 U U
3 U U
4 Seen U
5 U Deleted
6 U U
You may work out what happens here!
If expungelimit is more than 1, the numbers could become off by more
than 1 depending on how many seen+delete flags were stored. For
'fetchall', all the deleted mails would be downloaded again.
Here is a patch which tries to play safe by expunging right at start:
======================================================================
diff -Naur fetchmail-5.9.6.orig/imap.c fetchmail-5.9.6/imap.c
--- fetchmail-5.9.6.orig/imap.c Sat Dec 22 10:35:33 2001
+++ fetchmail-5.9.6/imap.c Mon Dec 31 13:29:04 2001
@@ -519,6 +519,23 @@
/* no messages? then we may need to idle until we get some */
if (count == 0 && do_idle)
imap_idle(sock);
+
+ /*
+ * We should have an expunge here to
+ * a) avoid fetching deleted mails during 'fetchall'
+ * b) getting a wrong count of mails during 'no fetchall'
+ */
+ if (!ctl->keep && count > 0)
+ {
+ ok = internal_expunge(sock);
+ if (ok)
+ {
+ report(stderr, GT_("expunge failed\n"));
+ return(ok);
+ }
+ if (outlevel >= O_DEBUG)
+ report(stdout, GT_("%d messages waiting after expunge\n"),
count);
+ }
}
*countp = count;
======================================================================
Note that if something has been expunged, we are counting on EXISTS
being returned by the protocol! If nothing gets expunged, EXISTS is
normally not returned (unless new mail has arrived) and count will not
change then.
Maybe, something similar has to be done for other protocols.
Sunil Shetye.