Hi This was the response I got from Frantisek and I thought it would good if
it were posted in the group.
Regards
Rishi
----- Original Message -----
From: "Frantisek Brabec" <frb_97(_at_)yahoo(_dot_)com>
To: "Rishi Gangoly" <rishi(_at_)theargoncompany(_dot_)com>
Sent: Friday, June 28, 2002 1:26 AM
Subject: Re: Fw: [fetchmail]UIDL of processed messages not stored in case of
error
You won't lose any email due to presence/absence of
the uidl flag. It is used to track which messages have
been previously seen and which are new. This obviously
only plays any role when you leave messages on the
server while using the POP protocol. The idea is that
you do not download already seen and downloaded
messages over and over.
If you specify 'uidl', it means that fetchmail will
keep a database of already seen messages and won't
download those already in the database in any
subsequent polling cycle. If you do not specify uidl,
it doesn't care.
F
--- Rishi Gangoly <rishi(_at_)TheArgonCompany(_dot_)com> wrote:
Thanks for responding. I've been trying to
understand the importance of the
uidl option.
In the sample .fetchmailrc config file
---------
poll server.com protocol POP3 options uidl username
"xyz" password "abc"
---------
If I remove the options uidl setting, will I loose
any email it the
connection breaks?
What purpose does the uidl option provide? I read
the man page and did not
understand too much. Can you help explain?
Thanks
Regards
Rishi
----- Original Message -----
From: "Frantisek Brabec" <frb_97(_at_)yahoo(_dot_)com>
To: "Rishi Gangoly" <rishi(_at_)theargoncompany(_dot_)com>
Sent: Thursday, June 27, 2002 10:36 AM
Subject: Re: Fw: [fetchmail]UIDL of processed
messages not stored in case of
error
I think it showed up in the sources eventually.
There
was not much if any discussion after this email as
far
as I remember.
F
--- Rishi Gangoly <rishi(_at_)TheArgonCompany(_dot_)com>
wrote:
Did Eric respond to you?
Regards
Rishi
----- Original Message -----
From: "Frantisek Brabec" <frb_97(_at_)yahoo(_dot_)com>
To: <esr(_at_)thyrsus(_dot_)com>
Cc: <fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org>
Sent: Saturday, May 12, 2001 10:01 PM
Subject: Re: [fetchmail]UIDL of processed
messages
not stored in case of
error
Eric - adding the single line as I suggested
in
the
option a) below is all it takes. So those few
lines in
the area would now look as follows:
if ((sdp->val.status.num == num)
&& (!toolarge || oldmsg)) {
sdp->val.status.mark = UID_SEEN;
save_str(&ctl->oldsaved, sdp->id,
UID_SEEN);
}
If the message gets removed from the server
after
delivery but there is a problem in the same
session
later on (and oldsaved is used to create
.fetchids),
this entry will be stored in the file even
though
the
message is not on the server (but then again,
it
might
as some servers do not proceed with the
deletion
if
the session was not terminated correctly as I
understand). It's not a problem though, the
entry
will be garbage-collected next time.
I've tested it in my setup (specific server
etc)
but I
can't test it extensively on all kinds of
email
servers in various situations... Hope it's a
change
straightforward enough to be considered.
F
--- "Eric S. Raymond" <esr(_at_)thyrsus(_dot_)com> wrote:
Frantisek Brabec <frb_97(_at_)yahoo(_dot_)com>:
Let's consider a situation (POP3 server,
local
UIDL
management on) when there are 5 new
messages
on
the
server. Let's say 3 of them get downloaded
successfully and they get delivered ok.
Then
there
is
some problem afterwards that causes
fetchmail
finish
with some error code (e.g., Protocol (4)).
In
such a
case, the procedure uid_swap_lists is not
called
which
basically means that the .fetchids file
will
remain
the same as it was before fetchmail's
execution.
This
is despite the fact that several messages
were
successfully retrieved and delivered.
This
results in
these messages being re-fetched and
re-delivered
next
time fetchmail is run.
My question is, would it be possible to
mark
the
delivered messages as SEEN even though
there
was
an
unrelated error encountered during the
same
session?
I see two ways of doing it:
a) we can modify the code in driver.c
(roughly
line
2350 in 5.7.5) so that when the SEEN flag
is
set
in
'ctl->newsaved', the same entry is also
inserted
into
'newsaved' - for instance by adding the
following
line:
save_str(&ctl->oldsaved, sdp->id,
UID_SEEN);
This way, the fact that this message was
seen
will
be
preserved for the next session regardless
of
whether
.fetchids will be created from 'oldsaved'
or
'newsaved'
b) If we cannot do uid_swap_lists because
of
errors
(fetchmail.c, line 627 in 5.7.5), we could
copy
all
entries from 'newsaved' marked as SEEN to
'oldsaved'
if they are not already there.
If you'll develop and test a patch for this,
I'll
consider it.
--
<a href="http://www.tuxedo.org/~esr/";>Eric
S.
Raymond</a>
Morality is always the product of terror;
its
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com