GNOME Bugzilla – Bug 402843
Remove Junk/Deleted flag when moving out of real Junk/Trash folder
Last modified: 2015-08-31 19:19:58 UTC
Please describe the problem: I observe the following behavior of copying & moving messages from Trash or Junk to a regular folder: - Copying from Trash marks the copy as not deleted, so it appears in the target folder. - Copying from Junk leaves the copy marked as junk, unless the target folder is the message's original location. This means that while it is physically copied, its duplicate appears in the Junk folder together with the source. - In both cases copying to the original location actually moves the message instead of copying: bits are changed in place. - In all cases moving behaves the same as copying. It's definitely confusing that moving from Junk to another folder actually makes a copy which appears in Junk. And it's confusing that copying from Junk to the original location actually removes the original (does it retrain spamassassin?). It's not clear what should be the correct behavior, considering that the illusion presented to the user (Trash and Junk are separate folders) differs from the physical representation (deleted and junked messages are stored in their original folders). In particular moving a message between two regular folders causes its copy to appear in Trash, which means that Trash is already somewhat special wrt. moving, and it's hopeless to have a semantics which is fully consistent with either point of view. In any case: moving being equivalent to copying is confusing, treating copying to the original location differently than copying to some other folder is confusing, and treating the junk bit differently than the deleted bit is confusing. And it's more important to be useful than to be consistent. Sigh. Here is an alternative semanics (A), mostly consistent with the illusion presented to the user, except that when moving to a different folder than the original, the original appears in Trash (same irregularity as when moving between regular folders). It still includes all the three confusing distinctions, but in different cases than currently: - Moving from Trash or Junk to the original location clears the deleted/junked bit (as currently). - Copying from Trash or Junk to the original location makes a duplicate with a cleared bit (differs from current). - Copying from Trash or Junk to some other folder makes a copy with a cleared bit (differs from current for Junk). - Moving from Junk to some other folder is equivalent to copying followed by deleting the original, i.e. the original appears in Trash (differs from current). - Moving from Trash to some other folder is equivalent to copying, as it's meaningless to delete from Trash (as currently). Unfortunately this semantics would be unacceptable for me, because it would take away the operation which triggered the whole issue: namely ensuring that junk is physically stored in a particular folder, while still marked as junk. This operation is important for two reasons: controlling which junk messages are removed when a folder is removed, and making possible to retrain spamassassin in the future (since Evolution prefers to physically mix junk with non-junk). This operation is currently tricky, but at least it's possible: namely only messages from other folders than the intended target must be selected, because moving to the original location would unjunk them; and they will be copied no matter whether copy or move is requested, so the originals must be deleted separately afterwards. Sigh. Here is a another semantics (B), which maintains the illusion about a separate folder only in the case of Trash, but doesn't pretend that Junk is kept separate from the original folders: - Trash is treated as in semantics (A). - Copying from Junk creates a duplicate junk in the specified folder (as currently except when copying to the original location). - Moving from Junk to the original location has no effect (differs from current). - Moving from Junk to some other folder is equivalent to copying followed by deleting the original; the original appears in Trash, and the created copy is still junk (differs from current). Thus I propose one of the following: - Change the semantics to (B). - Change the semantics to (A), but provide some other operation to physically move junk between folders while keeping it as junk. - Find another semantics. BTW, perhaps unhiding deleted messages in a folder should show junked messages as well. Steps to reproduce: See above. Actual results: See above. Expected results: I'm not sure what exactly to expect. Does this happen every time? Yes. Other information:
Thanks for a bug report. As far as I can tell (and tested), the Junk/Deleted flag is removed when moving out of virtual Junk/Trash folders. The problem with IMAPx is with real Junk/Trash folders, it worked wrong there. You didn't mention above whether you use IMAP or other mail store, thus I suppose it is IMAP related. I fixed this with the below commit. Created commit 548c81c in eds master (3.17.92+)