maemo.org Bugzilla – Bug 5634
Deleted IMAP messages are not expunged
Last modified: 2010-03-15 20:56:11 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: OS 41-10 STEPS TO REPRODUCE THE PROBLEM: Delete an E-Mail on an IMAP4 account using the Maemo E-Mail client. EXPECTED OUTCOME: Mail will be deleted and is no longer available and visible. ACTUAL OUTCOME: Mail gets only marked as deleted and will still be visible in some E-Mail clients. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: doesn't matter
Did you close Modest inbetween? Did you start the other email application after closing Modest? What are the exact steps in a timeline?
Yes, I have closed Modest inbetween and I have started the other E-Mail client after closing Modest. The timeline is: - start Modest - delete mail - close Modest (this doesn't really matter it seems) - start the other E-Mail app (Axigen Webmail in my case) - see the "deleted" mails still there, but striked out, i.e. not really deleted but only marked for deletion No matter how often I reopen the other mail client, the mails are still there.
Confirming, deleted flags are stored but the folder isn't expunged. Reminds me of bug 4592 a bit. Not sure if this is a bug or enhancement.
I would say it's a bug. What is a "delete" option good for if it doesn't delete but only hide (for some clients)? ;)
How is bug 2536 related, if at all?
(In reply to comment #5) > How is bug 2536 related, if at all? Only very indirectly: if deleted messages are not expunged, another modest instance (running on another machine) can undelete them in certain circumstances.
We fixed several issues about syncing flags to the server. Basically we don't do that until the user closes the headers window. This way we perform all the operations in the server with a single call. Imagine that the user reads some emails, deletes some others, and mark a couple of them as unread. If we sync that information with the server as it happens, we'll generate a lot of traffic, and thus a potential increase in cost for the user (if using GPRS for example). We recently added a new scenario where the flags are synced and it's when the user presses send&receive in the headers window. Can you confirm what I say?
The problem still remains in OS 2009.42-11 (modest 3.0.17-rc66+0m5).
The first update should include the stuff that Sergio listed in Comment 7.
This problem is reproducible even with a Gmail account, when you delete a message from the [Gmail]/Spam or [Gmail]/Trash folders; Email app doesn't show it anymore, but the message is still present on the server.
(In reply to comment #10) > This problem is reproducible even with a Gmail account, when you delete a > message from the [Gmail]/Spam or [Gmail]/Trash folders; Email app doesn't show > it anymore, but the message is still present on the server. > As I said, messages are not immediately expunged when deleted. We expunge messages when the user closes the folders window or when a send&receive (automatic or manual) is done.
(In reply to comment #11) > As I said, messages are not immediately expunged when deleted. We expunge > messages when the user closes the folders window or when a send&receive > (automatic or manual) is done. I know Sergio, I tried with both automatic and manual send&receive, the emails are no shown inside the Email app, but they're still present on the Gmail web interface, even after a whole logout/login cycle.
(In reply to comment #12) > (In reply to comment #11) > > As I said, messages are not immediately expunged when deleted. We expunge > > messages when the user closes the folders window or when a send&receive > > (automatic or manual) is done. > > I know Sergio, I tried with both automatic and manual send&receive, the emails > are no shown inside the Email app, but they're still present on the Gmail web > interface, even after a whole logout/login cycle. What version of Modest are you using? Or what version of the platform are you using?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > As I said, messages are not immediately expunged when deleted. We expunge > > > messages when the user closes the folders window or when a send&receive > > > (automatic or manual) is done. > > > > I know Sergio, I tried with both automatic and manual send&receive, the emails > > are no shown inside the Email app, but they're still present on the Gmail web > > interface, even after a whole logout/login cycle. > > What version of Modest are you using? Or what version of the platform are you > using? BTW note that for GMail for example, it's not enough with reloading the page in your browser. You have to switch between folders to get the most updated list.
I have 1.2009.42-11 on my N900; please note that I even tried to logout and login again into Gmail, but the emails are still there.
FYI, I'd very much like an option to *not* have the maemo reader expunge at all. I'd rather have my desktop client do the expunging so I can be careful about when it's done.
(In reply to comment #16) > FYI, I'd very much like an option to *not* have the maemo reader expunge at > all. I'd rather have my desktop client do the expunging so I can be careful > about when it's done. > Well, I support your opinion, we just need an option to decide what to do when we want to delete a mail, the real problem is the current situation, where Modest doesn't show the emails anymore, like they were gone, but they're still there, on the server.
FYI, I agree and have tested it as well. I can't get it (on a shipped N900) to ever do an expunge regardless of how far up the window/folder/application stack I go. Granted, I sort of want this so I don't care, but I can reproduce it!
This is a big problem with Advanced IMAP settings for Gmail. I use this Gmail lab tool to make Gmail to move messages to Gmail's trash folder after I delete those via IMAP. I works nicely with S60 email client. With maemo (N800 and N900) deleting mails just makes mails unvisible for maemo mail but doesn't move those from my Gmail's inbox to trash folder.
The problem was that we're invoking the remove method in tinymail always with expunge=FALSE. That's why it was not working, as simple as that. The reason why expunge was FALSE was because some function was returning some default value that was not expected when we first wrote it. Anyway, it was fixed in modest-3-2 a5a62061267da3efd7e01b5dc9deee4556dbe27d master 61ca2715672c690010346ad6099fa360212f7d0d Thx for reporting!
*** Bug 7069 has been marked as a duplicate of this bug. ***
On my N900 email still not delete on server no matter if i check the option "keep messages on server" or not...always no delete. I've tried updateing software but it tells me no update is available from "application management". How to understand which modest version i have???
(In reply to comment #22) > On my N900 email still not delete on server no matter if i check the option > "keep messages on server" or not...always no delete. That setting does not apply to IMAP accounts, you probably want bug 2922. (In reply to comment #20) > Anyway, it was fixed in > modest-3-2 a5a62061267da3efd7e01b5dc9deee4556dbe27d Still reproducible on 2.2009.51-1 (as expected, since that only ships modest 3.1.18+0m5).
(In reply to comment #23) > (In reply to comment #22) > > On my N900 email still not delete on server no matter if i check the option > > "keep messages on server" or not...always no delete. > That setting does not apply to IMAP accounts, you probably want bug 2922. No, i have POP account and i confirm that when i delete a message it disappear from N900 but remain on server inbox. "Leave messages on server" in NOT CHECKED. Seems like this option is not working... I have also tried with an IMAP account: if i delete a message it disappear from device but still present on server...no good thing!!! I think these are BUGS still OPEN and not RESOLVED > (Comment #20 from Sergio Villar Senin) I do not know how to understand what version number i have of modest but i can say that my phone have all the updates from these repositories: -Nokia apps -Nokia system software updates -maemo extras ans still the problem is present.
(In reply to comment #24) > I think these are BUGS still OPEN and not RESOLVED Please remove unneeded quoting for the sake of readability here, and please read https://bugs.maemo.org/page.cgi?id=fields.html#resolution (especially the definition of "FIXED") before adding comments.
(In reply to comment #25) > (In reply to comment #24) > > I think these are BUGS still OPEN and not RESOLVED > Please remove unneeded quoting for the sake of readability here, and please > read https://bugs.maemo.org/page.cgi?id=fields.html#resolution (especially the > definition of "FIXED") before adding comments. Ok now i understand ;-)
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).