Quoting from Eric S. Raymond's mail on Mon, Dec 24, 2001 at 11:30:36PM -0500:
Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com>:
diff -Naur fetchmail-5.9.6.orig/imap.c fetchmail-5.9.6/imap.c
--- fetchmail-5.9.6.orig/imap.c Thu Nov 8 22:00:01 2001
+++ fetchmail-5.9.6/imap.c Sat Dec 22 10:35:33 2001
@@ -576,6 +576,7 @@
*newp = unseen;
expunged = 0;
+ deletions = 0;
return(PS_SUCCESS);
}
What put you on to this being necessary?
After STORE commmand succeeds, deletions is increased.
After EXPUNGE commmand succeeds, deletions is reset to zero.
So, if the connection breaks between STORE and EXPUNGE, deletions
remains at 1. (Assumung expungelimit is 1 here.)
In the daemon mode, the same value of deletions is used in the next
poll.
So, at the beginning of the next poll, expunged is equal to 0,
deletions is equal to 1.
So, the transaction goes as:
number expunged (number-expunged) deletions
Start of first poll - 0 - 0
FETCH 1 0 1 0
STORE 1 0 1 1
EXPUNGE 1 1 1 0
FETCH 2 1 1 0
STORE 2 1 1 1
EXPUNGE (failed) 2 1 1 1
End of first poll - 1 - 1
Start of second poll - 0 - 1 (this should
have been reset to zero)
FETCH 1 0 1 1
STORE 1 0 1 2
EXPUNGE 1 2 1 0
FETCH 2 2 0 0
^
(this should be one)
(number is a local variable, so it is not defined everywhere)
`number' is incremented by one before every FETCH.
`expunged' is incremented by `deletions' after every EXPUNGE.
`deletions' is incremented by one after every STORE.
`number-expunged' is used for the FETCH, STORE statements.
As you may see, in the second poll, the STORE caused the deletions to
be set to 2 causing the expunged to be set to 2 later.
So, in the second poll, a FETCH 0 is issued after one mail has been
successfully downloaded!
Initialising it once only does not work when the program runs in
daemon mode.
Sunil Shetye.