Comment 1 Andre Klapper 2008-08-19 23:02:48 UTC

Thanks for reporting this. This bug report isn't very useful because it doesn't
describe the bug well.

There is a template for a good reason. You don't tell us the hardware you use
or the exact software version. This makes it impossible to reproduce.
Please also try to find out a pattern when this happens.

If you have time and can still reproduce the bug, please read
https://bugs.maemo.org/page.cgi?id=bug-writing.html and add a more useful
description to this bug.

itos veersion: 4.2008.30-2

ugh, sorry about these bug entries, thats what i get for writing reports while
staying up for more then 12 hours...

anyways, the hardware is a N800.

the modest setup are two pop3 accounts, set to download only headers.

basically what happens is that i have a unread mail in the inbox, i attempt to
open it, and its gone from the inbox. no delete confirmation dialog, no
"retrieving" message in the lower right corner, nothing.

its just gone.

from what i can tell by my experimentation so far, the accounts journal see it
as deleted. but the mail content itself seems to not be downloaded, so a
removal of the journal and a check of the account will make the mail appear as
unread again.

but that do not stop it from happen again, with either the same mail or with
some other mail.

Comment 4 Andre Klapper 2008-09-08 21:45:00 UTC

I assume there are no other clients accessing the same mailbox?
A pattern to reproduce would be great, but I know it's often hard to find...

so far i have seen no pattern. the mails can be html or plain text, have
attachments or not. basically i cant tell if a mail will download or will
vanish.

and no, there was no other client accessing the pop account between the headers
being downloaded and the mail itself, that im sure of.

also, would not modest give me a error message of some sort of that was the
case?

Comment 6 Andre Klapper 2008-09-10 17:34:24 UTC

Hmm, I wonder whether this is some kind of Modest UI bug, or whether it's some
kind of connection issue to the mail server. Strange bug so it's hard to guess,
hence asking again for a connection log...

You already know these instructions from the other bug you've filed:

Please start a X Terminal window and enter
    export "CAMEL_DEBUG"="all"
to enable the debug mode of the mail library. After that, enter
    /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1
to start the email application. Then connect to the mail server.

When this happens again, please attach the logfile named "log" here (please
check for confidential data before attaching).

i suspect that the result will be much the same as the other log, but ill give
it a go...

Created an attachment (id=932) [details]
modest log

attached the log as requested...

didnt see the issue happen while catching the log tho, so im not sure how
useful it may be...

Comment 9 Andre Klapper 2008-09-11 16:21:07 UTC

(In reply to comment #8)
> didnt see the issue happen while catching the log tho, so im not sure how
> useful it may be...

Then it's not really useful. A log when it's happening would be great, or/and a
second person confirming this problem.

(In reply to comment #9)
> (In reply to comment #8)
> > didnt see the issue happen while catching the log tho, so im not sure how
> > useful it may be...
> 
> Then it's not really useful. A log when it's happening would be great, or/and a
> second person confirming this problem.
> 
I can confirm that it happens to me too. It happens most often if I am using a
slow connection (Bluetooth modem through my phone)

i just noticed something.

i tried to open a mail with the center dpad, and the retreiving bar didnt show
up. tried mail->open in the menu, same.  then i taped the mail (it had focus so
only one tap should open it). and poof it was gone.

Comment 12 Andre Klapper 2008-09-15 15:01:59 UTC

jinlaca: If you can reproduce this quite easily, can you please provide a log
*when this is happening* as described in comment 6?

*** This bug has been confirmed by popular vote. ***

I am running into the same problem. From some experimenting to when this occurs
here a description of the scenario in which I can reproduce this:

I am using POP3 which is limited to retrieving one mail each 1 minute (think
this is the timeframe). When retrieving the first mail within this timeframe
things act normal. But when trying to access a second mail (retrieving) from
the server the mail is deleted fro  the inbox as described in this defect.

To me this only happens if I happen to try to fetch mails too often wihin the
given interval.

Comment 15 Andre Klapper 2008-09-16 16:25:41 UTC

Jan: Can you please trigger this issue and provide a log, as described in
comment 6?

Created an attachment (id=937) [details]
maemo modest log file

I was able to reproduce the scenario. Find attached the log file recorded. I
retrieved one message successfully and the second request failed deleting the
message from the inbox.

Comment 17 Andre Klapper 2008-09-17 14:59:45 UTC

Yupp, the log says:

CamelException.setv(0x42c0dd40, 110, 'Message with UID
6b7542c5960684b64c7c6e005f7ab572 is not currently available on the POP server.
If you have a web E-mail account with POP access, make sure that you select to
export all E-mails over POP for mail, the ones that have already been
downloaded too. Also verify whether other E-mail clients that use the account
are not configured to automatically delete E-mails from the POP server.')

what would be interesting would to access the account via some web interface to
verify that the mail was still on the server. it probably was.

(In reply to comment #17)
> If you have a web E-mail account with POP access, make sure that you select to
> export all E-mails over POP for mail, the ones that have already been
> downloaded too. 
This workes fine with other POP3 capable systems. And I never had to set a flag
on the serverside of the provider to support that.

> Also verify whether other E-mail clients that use the account
> are not configured to automatically delete E-mails from the POP server.')
No other system accessed the mail box before. Looking into the WebUI they are
still showing up.

(In reply to comment #18)
> what would be interesting would to access the account via some web interface to
> verify that the mail was still on the server. it probably was.

Yes the mail is still available eventhough it vanished from Modest inbox.

I managed to find a workaround that for me seems to work. Here a step by step
how to avoid:
1. Instead of downloading the new message open a message before or after the
new mail that has already been downloaded before.
2. Instead of opening the new mail from the inbox use the 'nest', 'prev' button
to navigate threough the new messages.

Though this does not solve the problem and is agreed some overhead it prevents
nasty deletion of mails from the Inbox.

If this only happens with POP3 then we can safely close this bug because it was
a known problem in the POP3 code of tinymail.

I committed the fix into tinymail in r3728 (trunk). So it'll be available soon.

Comment 23 Andre Klapper 2008-10-14 12:54:16 UTC

Sergio: The internal ticket was fixed for week31 so this should be already
fixed in the 4.2008.36-5 update.

Closing as FIXED, can anybody of the reporters please verify this?

have not seen it happen so far so i would say its fixed.

Cool, then I'd close this Andre