Comment 28 for bug 365270

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