Re: [fetchmail-devel] lost UIDs

[Matthias A. <mat...@gm...>]

Manfred Weihs schrieb am 2005-03-06:

> You might have a look at the attached patch. It removes the (completely 
> unnecessary) recursion in free_str_list. So it reduces stack usage and 

OK that far. However...

> avoids possible problems with very long lists. Furthermore I slightly 
> changed the interface and replaced the pointer to a pointer to the first 
> list element by just a pointer to the first list element. I think, this 

...now is not the time for interface changes, as the next fetchmail
release has been long overdue and intrusive changes should wait.

So I've left the interface unchanged and just removed the recursion. I
have ignored your change to the __UNUSED__ code which isn't compiled in.

> > Perhaps keeping all spam mail on the server isn't the best idea then?
> 
> But since I fetch the mails from two PCs (at home and at work), I have 
> to leave them on the server. Maybe I should delete mails from the server 
> more frequently. But I have to do this manually, because fetchmail does 
> not support to keep the mails only for X days or to keep only the latest 
> X mails (the later would be very easy to implement, but according to the 
> fetchmail FAQ it will not be implemented due to political reasons).

Yup, that was ESR's opinion. I don't share this view, but the UID code
needs to be cleaned up *massively* before any feature changes should be
allowed in. The UID code is a mess, and it's not used for IMAP.

> And an automatic cron job is no alternative, because, in this case I
> cannot be sure, that fetchmail got all the mails before the cron job
> deletes them. The deletion should be done _after_ fetchmail delivered
> the mails locally, ideally within the same pop3 session.

Right. If you can live with a slower software that has less features in
several areas, Charles Cazabon's getmail-4 has this feature.

-- 
Matthias Andree