GNOME Bugzilla – Bug 329946
sends a copy of mail to TRASH on move
Last modified: 2010-05-28 17:02:10 UTC
Distribution: Debian testing/unstable Package: Evolution Severity: minor Version: GNOME2.12.2 2.4.x Gnome-Distributor: Debian Synopsis: sends a copy of mail to TRASH on move Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: 2.4.x Description: Description of Problem: when you move a message from INBOX to another folder, it is moved, but a copy of it goes to the TRASH, which can confuse users, making them think one of their messages was deleted. Steps to reproduce the problem: 1. move a message from INBOX to any other folder. 2. check the TRASH, it will be there as well How often does this happen? Always ------- Bug created by bug-buddy at 2006-02-04 23:20 -------
This is correct bavior. For explanation: Moving a mail actually is "copy and delete". This is the correct method to use. Since the mail is not physically moved, but the data can be copied only. After copying is done successful, the source mail is deleted. Related note: Deleting a mail actually marks the mail for deletion, but does not remove the mail physically. Disable "View / Hide Deleted Messages" to see the "deleted" messages in any folder. The Trash folder actually is a Search Folder, displaying all marked-for-deletion (aka "deleted") mails. Thus, with Hide Deleted Messages disabled you can see the mail you just moved being marked as deleted in the source folder. Thanks for taking the time to report this issue! Feel free to report any further bugs you find. (Closing this bug report.)
*** Bug 330501 has been marked as a duplicate of this bug. ***
Again, where do we think we're going forcing users to understand this huge amount of computer non-sense? The bug reporter is my father, and he was screaming because he thought the mail he tried to move had been deleted, and I do not blame him, as something found on the Trash leads to such conclusions. I don't care about Evolution does behind the scenes, I care about what its interface makes users think.
Hi Karsten, Quoting you: "For explanation: Moving a mail actually is "copy and delete". This is the correct method to use. Since the mail is not physically moved, but the data can be copied only. After copying is done successful, the source mail is deleted." Why mail behaviour is different than files and directories in every filesystem? Do you remember that "everything is a file", right? Thanks, Gustavo Franco
quoting comment 4: > Why mail behaviour is different than files and directories in every > filesystem? Do you remember that "everything is a file", right? Because it is not a file. Whatever storage your IMAP server uses is up to the IMAP server. One mail can be a file, but it often is just some text part inside one huge file or even stored in an SQL database. This is an implementation detail of the IMAP server and Evolution can not do anything about this. BTW, "everything is a file" applies to a fundamental UNIX design concept, which is entirely unrelated to this issue. Again, as mentioned in bug 330501 comment 3, the IMAP protocol does not support a "move" command, AFAIK. Any client can resort to "copy and delete" only. I am not sure if IMAP supports expunging (physical removal) of *single* mails. If it does not, there is no way Evo could work around this using the IMAP protocol. I have been trying to be *helpful* by explaining the issue and why it is implemented this way. I don't like closing bugs without explaining the details. I want happy users and happy bug reporters. Anyway, I am going to assign this bug to me, and will discuss this issue again with the developers. However, I don't know yet whether this can be changed at all. Setting this bug to NEEDINFO for the time being.
Gah, ASSIGNED, not NEEDINFO, to make bugzilla happy. Sorry for the noise.
Sory for bugging you about a duplicate bug (pun intended). I tried to use Thunderbird (heresy! ;-)) and it does not exhibit this behaviour. I think that Thunderbird actually has a physical Trash folder where it "moves" all mail and hides all messages marked as deleted, simulating, in a more user friendly way, the "move" behaviour. Could this be possible to implement? I beleive it is a more sensible behaviour for users than the current copy and delete stuff. Thanks for your explanation and time, V. Seguí
Like I said, I do not care at all about what Evolution does behind the scenes for this bug, because users do not see it, and the whole point here is scaring users. As long as it doesn't show the message the user hasn't deleted in the Trash, it's already good enough.
As was mentioned, the way Moz-Mail does this is to hide deleted messages in the original folder and copy to a physical Trash folder (at least this is the default config). There are other configs that you can set Moz-Mail to do tho, iirc. It's been a while tho... Anyways, that said, there's already a feature request to support physical Trash folders in Evolution as well, which would solve this problem.
*** Bug 331872 has been marked as a duplicate of this bug. ***
We already have 2 known duplicates for this bug. I assume it annoys a considerable amount of people, and something near 100% of those who know it. I'd really recommend putting some time into fixing this.
*** Bug 335687 has been marked as a duplicate of this bug. ***
*** Bug 364211 has been marked as a duplicate of this bug. ***
*** Bug 399320 has been marked as a duplicate of this bug. ***
In order to add to the severity of this bug, consider the following use case: I have a webmail account which allows access to the mails via POP3 (no IMAP) which I use. Locally I sort my incoming mails by moving them into several folders. Also I occasionally need to access these e-mails via web interface, thus the mails must not be removed from the server. Accessing the mailbox via POP3 from several computers leads to the same conclusion: Allow (local) mail moving without deleting any mails on the server. When I tried out Evolution with a test account (fortunately not with the real one!) I discovered that the local mail move deleted all the moved mails on the server as the move operation in Evolution consists of copying and deleting the original mail. For me and anyone with the above use case this bug is an absolute show stopper.
I add that the fact that Evolution does not expunge source folder after "copy to destination folder" and "mark original mail for deletion" can quickly lead to quota problems as the mail is duplicated. If the mail is later deleted in the destination folder, it will also appear twice (or more if it was further moved and deleted) in the trash virtual folder which is confusing. Problem is that expunging source folder would also erase all mails trashed from this folder which is dangerous (lots of people like to keep archived trashed mails, I keep mine two years). So this would also require the possibility for Evolution to implement delete as "move to (physical) trash folder" rather than as "mark for deletion". See (for example) bug #351413.
*** Bug 490506 has been marked as a duplicate of this bug. ***
*** Bug 492819 has been marked as a duplicate of this bug. ***
*** Bug 549840 has been marked as a duplicate of this bug. ***
Wow, this bug was reported in 2006. Now it is 2009, almost 2010. The status remains "ASSIGNED". Maybe "WILL NOT FIX" is more accurate. I think the handler(s) of this bug are under the impression that they get to decide what is and isn't a bug. This simply is not true. The users decide what is or isn't a bug. The job of a developer is to make the software do what the user expects it to do. Any deviation from the "expected behavior" is a bug. When I select a message and drag it to another folder I expect the message to disappear from the current folder and reappear in the destination folder. I do not expect the message to be "marked as deleted" in the current folder. As a user, I don't care what method is used to make this happen; I simply care that my messages are moved as expected. Of course, this is free software, and no developer can be forced to do anything s/he does not wish to do. It is obvious to me that either the bug handler(s) do not wish to take this bug to the developers, or the developers themselves are not willing to change the current behavior. In either case, there is nothing the community can do to force the issue. I believe in Open Source software. I believe Open Source is the way of the future. I believe in the power of a community coming together to do great things, to push the limits. But, despite all I believe, I know that issues like this spell doom for even the greatest projects. We simply can't allow ourselves to bleed to death over issues like this. The fix for this bug is simple. Make a real Trash folder and make an option to use it. Those who want to see duplicate messages pile up every time they move a message can simply opt to use the default IMAP behavior, without a real Trash folder. Those who are expecting a move operation to actually move the message, without duplication, can elect to use the real Trash folder instead of the virtual Trash folder. I really hope we don't have to wait 4 years for such a simple fix. Most people won't wait, they will simply use other software.
I moved to thunderbird last week. Can't believe I hang in so long. Removing CC.
Karsten, I don't wish to sound aggressive or disrespectful in any way; please keep that in mind when reading all the following, and accept my apologies in advance for anything that may - unintentionally - offend you. I know you were trying to be helpful when you first explained the inner-workings of Evolution and IMAP (even though the original bug reporter did not have the slightest idea of what IMAP might be) and the reason why this appears to be a bug to users. I honestly thank you for that (and so much more). The point here is, though, at least as far as I am concerned (and disregarding the potentially more serious issues that others came up with because I'm not directly affected), all about our Interface Guidelines. It's as simple as that: a user should not see anything in the "Trash" folder unless they have deleted it, because a Trash is not where anyone would expect to find moved items (and trying to explain the IMAP protocol to them does not seem to be an option). Fine, take the bug report as a wishlist item, if you want. However, this undesired behaviour persists after almost four years. I know what it is like to work on things you want to in your free time, just as well as I am sure you have more important stuff to work on, even in Evolution itself, but could you at least share any progress you may have made or any conclusions you may have drawn from your discussions with other developers? At this point, I don't really know what I'm talking about, for I never really looked carefully into the source codes of either Evolution or any of the related libraries (sorry I can't write a patch), but wouldn't it be possible to just somehow flag moved messages (what may be possible for some backends but not for others) so that they are filtered out from the Trash display? Despite what is discussed on bug #206061, I do not think it has to be made sane in order to look sane and, from the angry comments above, it just seems people who filed the bugs expect at least some reaction to the unpleasant user experience they reported.
*** Bug 442394 has been marked as a duplicate of this bug. ***
I'd argue that this is really a duplicate of #206061, since a correction for that would make this go away entirely. I'm marking it as such. *** This bug has been marked as a duplicate of bug 206061 ***