Thanks Mathias, It not only "appears" in the Trash folder, it allocates place somewhere, and can be "undeleted". Now I wonder where the undeleted email will appear, since it has no original reference. It is incorrect to place it in the Intray and then "Move" it to where it belongs - that will produce another duplicate and a new entrance in the Trash.
Why no tag it as "DELETED" in Trash. Then it will not show, it cannot be "undeleted" and the number of emails remains the same. It is a problem on both sides - because the MBOX files gets a wrong number of messages contained. If you search, you risk that emails are not found, because the search engine will look for the "n" emails it has been told is in the file. The search is not sequential, but will typically follow the received date - and skip those marked "Deleted". You cannot "grep" the MBOX, since that search will include the header and (encoded) attachments. The bug may be a source of a number of other issues. If you "compact" these - you risk loosing emails. Since most "Move" will be while running in the rules when the emails are received, making the inconsistency in the "Intray" only. My guess is that they regenerate the indexing every time new mail is received to reclaim space making this a "special" container. However moving from other folders later on. Consider usage of 3 folders, where a message is moved by rule from InTray to "To Be done". Then action cause the mail to be moved to "In Work" and then to "Completed". This will cause 3 entries in Trash. Now "UnDelete" one of these and run the regular rules on it and move it to "To Be Done" - with a duplicate in "Completed". "Move" on an IMAP server or any other server is just an update of an index on the server side. I wonder how many patches have been done on the "server side" (MBOX/IMAP) because of this. -K On to-16.09.2010 23:41, Mathias Kende wrote: > Disregarding the "database" problem, the point of view of the submitters > of the two bug that were marked as dupplicate of this one is quiet > different. There problem (and mine) is that, whenever a mail is moved > along, a copy _appears_ in the trash folder (both with local mail and > with IMAP folders). > > I understand the technical reason not the delete the message from the > server/mbox file immediately. But, as it is a technocal restriction, the > user need not be aware of that. Read bug 209214 to see why people > dislike this way of functionning. > > Adding a mechanism (on evolution's side) which hide these message from > the trash folder until it is really expunged. Moreover, I believe that > expunging the email folders and emptying the trash folder are two very > different thing. One is a detail of the implementation and should be > hided from the user, the second is a standard part of user interfaces > and should act the same way as it always act (or be called differently). > The current situation is very misleading. > > But this is more an upstream issue. > -- Move is Copy + Thrash, should be Move that removes all traces of the first. https://bugs.launchpad.net/bugs/365270 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
