[Users] Claws 3.9.2 - two _really_ annoying issues...

[kardan]

On Fri, 9 Aug 2013 14:06:45 +0200
Paul Rolland (ポール・ロラン) <rol at witbe.net> wrote:

> I'm using POP3, and I have several accounts configured. 
> ...
> If the "Receive" operation I start manually last longer than this
> account retrieve interval, and that this account is configured for
> automatic retrieval, I end up with _two_ retrieve operations at the
> same time. I can see by the "progress counters" at the bottom right
> of the Claws window alternating their counts of messages, for example:
> 10/46 then 30/46 then 10/46 again, and so on.
> When that happens, I kill Claws to avoid more mess...
I use IMAP also with sub-DSL speed (fortunately not as slow as GPRS)
and increased the check interval lately. 15 min works fine for me as
claws is less busy now.
 
> This "Send" action results in all the emails received so far
> for the secondary account (POP still in progress) to be placed in the
> folder associated with the main account (the one used for the Send).
This sounds like an ugly bug. Please consider to file a report in [1]. I
will test if this is the same for IMAP and append if so.

> It may be important to note that this account (used to Send) is also
> configured with "Authenticate with POP before sending". Maybe the POP
> sessions are mixing each other ?
My impression: The session pointer for the receive task is overwritten
by the send task. As you see below pop3_session_new does not check if
there are running sessions, nor is the session stored account specific.

inc.c:512:      session->session = pop3_session_new(account);
static IncSession *inc_session_new(PrefsAccount *account)
{
        IncSession *session;
        cm_return_val_if_fail(account != NULL, NULL);
        if (account->protocol != A_POP3)
                return NULL;
        if (!account->recv_server || !account->userid)
                return NULL;

        session = g_new0(IncSession, 1);
        session->session = pop3_session_new(account);
        session->session->data = session;
        POP3_SESSION(session->session)->drop_message = inc_drop_message;
        session_set_recv_message_notify(session->session,
                                        inc_recv_message, session);
        session_set_recv_data_progressive_notify(session->session,
                                                 inc_recv_data_progressive,
                                                 session);
        session_set_recv_data_notify(session->session,
                                     inc_recv_data_finished, session);
        return session;
}

pop.c:516:Session *pop3_session_new(PrefsAccount *account)
Session *pop3_session_new(PrefsAccount *account)
{ 
        Pop3Session *session;
        cm_return_val_if_fail(account != NULL, NULL);
        session = g_new0(Pop3Session, 1);
        session_init(SESSION(session), account, FALSE);
        SESSION(session)->type = SESSION_POP3;
        SESSION(session)->recv_msg = pop3_session_recv_msg;
        SESSION(session)->recv_data_finished =
        pop3_session_recv_data_finished;
        SESSION(session)->send_data_finished = NULL;
        SESSION(session)->destroy = pop3_session_destroy;
        session->state = POP3_READY;
        session->ac_prefs = account;
        session->pop_before_smtp = FALSE;
        pop3_get_uidl_table(account, session);
        session->current_time = time(NULL);
        session->error_val = PS_SUCCESS;
        session->error_msg = NULL;
        return SESSION(session);
}
Please anyone tell me if I am wrong.

> Hope this will inspire someone... and I'm ready (and willing) to try
> any patch you may cook ;)
Thanks for reporting this. I rather not write a patch as I don't want
to be the one who is responsible to mix up your mails any further. :)
Hopefully someone else jumps in.

Good luck!

[1] http://www.thewildbeast.co.uk/claws-mail/bugzilla/enter_bug.cgi

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130810/76dd4f19/attachment.sig>