Comment 10 for bug 365270
Revision history for this message
| Knut (khf) wrote Re: [Bug 365270] Re: Move is Copy + Thrash, should be Move that removes all traces of the first. | #10 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Your interpretation of the named RFC and software engineering leaves a
lot to be appreciated related to semantics.
As you will see from several other bugs, "MOVE" is not the same as
"COPY" + "DELETE_ORIGINAL".
"MOVE" is similar to "RENAME" - no new instance is to be made.
In a object oriented explanation, its an "attach" with a "detach".
With the DELETE flag set, this allows another incoming email to use the
"Trashed" slot - since the code assumes that the copy by then is in the
Trash-bin.
In any system, "moving" an object means that the number of objects are
to remain the same before and after the operation. The "cardinality" is
to be consistent, and you cannot populate with repeated "Move"
operations. Should this be unclear in the refered Request for Comment,
include this comment and change the response. This is just like your car
- if your drive (move it), you do not get a new copy created in a local
trash dump that you can collect later should you regret the trip. You
still only have one car, and moving home will not create a third car
(nor object nor email). If the Linux community is of a different
opinion, wake up to the real world.
The bug made me decide to remove Evolution from the system, because it
introduce a high risk of loosing emails which renders the software
useless.
Bottom line is that I do not care about classification - and caution
others from using Evolution.
On Sun, 2009-04-26 at 23:23 +0000, Marc Deslauriers wrote:
> There is nothing wrong with Evolution. The behaviour is expected in an
> imap mail client. The "Trash" folder isn't actually a folder, but simply
> lists email that has the "deleted" flag set. When you move an email from
> Folder A to Folder B, a copy is made into Folder B and, if successful,
> the original mail gets the "deleted" flag set. In order to permanently
> erase the original message, an expunge command needs to be issued with
> Folder/Expunge. See RFC 3501.
>
> In any case, this is not a security issue.
>
>
> ** This bug is no longer flagged as a security vulnerability