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

[Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)]

Hello,

On Sat, 10 Aug 2013 14:30:13 +0200
kardan <kardan at riseup.net> wrote:

> > 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.

Looks like there is a "inc_lock_count" that is used to protect, but I'm
still checking all the details to make sure there is no way to bypass it.

Fact is that, if there is a way to go around the inc_lock_count check, then
you have that :
static gint inc_drop_message(Pop3Session *session, const gchar *file)
...
        /* CLAWS: claws uses a global .processing folder for the filtering. */
        dropfolder = folder_get_default_processing();

Yurk ! A global unique processing folder... So, yes, if a POP3 session goes
running at the same time another one is getting mails, and ended before,
then it'll probably go and process the emails, resulting in what I
experience.

Maybe a unique processing folder per account would be better ? 

Paul 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130811/18635994/attachment.sig>