On Mon, 13 Apr 2015 14:25:20 +0200 Ricardo Mones <mo...@debian.org> wrote:
> That's not possible. IMAP clients have not a clue about how the > server deals with messages. The current operations are already Yes they do per RFC3501: RFC3501> The server completion result response indicates the success or RFC3501> failure of the operation. It is tagged with the same tag as RFC3501> the client command which began the operation. Thus, if more RFC3501> than one command is in progress, the tag in a server completion RFC3501> response identifies the command to which the response applies. RFC3501> There are three possible server completion responses: OK RFC3501> (indicating success),NO (indicating failure), or BAD RFC3501> (indicating a protocol error such as unrecognized command or RFC3501> command syntax error). So when you receive an OK response with the same tag as the copy command you can in fact know that the copy command has completed successfully and safely issue a delete command. > grouped (notice the ranges) for hinting the server, but that's all a > client can do. The only difference with current method would be > one-by-one. Any other reordering can be as good or as bad as current, > since nobody knows what the server does. So your claim that my suggested change to the current method would have poor performance is without foundation as you cannot, by your own words, possibly know. > > > The log file segment I included resulted from a single bulk move at > > the user interface level which resulted in claws-mail issuing > > multiple copy commands over IMAP and not deleting any of the > > messages for which it got a response indicating success. > > There's no reason for issuing deletes, since we're copying all first. That is begging the question The point at issue is precisely whether it is a good idea to do that. My contention is that it is not for the reasons I've outlined. > > Anyway, imagine there's a DELE and the server drops the connection > after it. See? duplicates are still there, nothing improves. Maybe > less duplicates, but still some mess to be fixed, and you have to > repeat operation. Duplicates may still be there but as long as the client can manage to issue one pair of copy/delete commands before the connection is dropped there will still be progress and after sufficient reconnects all the copies of the messages being moved will eventually end up in the destination folder. It seems to me there is no good reason to have two copies of the same message in a single folder so deduplicating a single destination folder is a much safer option than trying to remove messages from the source folder that are already present in the destination folder. > That's theory also. In practice the command succeeds for a small > number of messages :) But yeah, you have a crappy server, you're No that's actual practical experience. The command fails uterly because it translates a move into a copy of a subset of the messages. > doomed to do things which wouldn't need to do with a decent server. > Don't know why the client is the one to blame. > Well I agree that the server is crappy (it is MS Exchange after all) but per RFC2683 section 3.1.1 the server is allowed to drop the connection and the client has to deal: RFC2683> If you are designing a client, you must not assume that you can RFC2683> access the same mailbox more than once at a time. That means RFC2683> RFC2683> 1. you must handle gracefully the failure of a SELECT RFC2683> command if the server refuses the second SELECT, RFC2683> 2. you must handle reasonably the severing of your connection RFC2683> (see "Severed Connections", below) if the server chooses RFC2683> to allow the second SELECT by forcing the first off, > Removing duplicates works equally well for one or for thousands of > messages, it's exacly the same effort. And would be a one time > operation only. > That assumes it actually gets that far. Which it does not. Also as above removing duplicates getting the removal of duplicates correct cross folder is not as easy to get right as removing them from a single folder. > Well, I understand your time is also involved, but given you have a > *faulty server* I think having only to invoke the duplicate removal As per RFC2683 above the server is not faulty just a PITA. Nevertheless I have raised this with the people responsible for it. So far no joy. William
signature.asc
Description: PGP signature
