Thus Spake ow...@bugs.debian.org (Debian Bug Tracking System): Debian Bug Tracking System writes: > > Hi William, > > > Sorry but what you're suggesting here would be extremely inefficient and > would make the movement of more than a few mails an everlasting process.
I think you have that backwards. The efficiency that matters is efficiency in the use of the users time. The mail move operation being fast is important only inasmuch as it contributes to this goal. Note that I am not suggesting moving one message at a time just reordering the existing copy and delete operations so that the deletes occur as soon as possible after the copy succeeds. I would have though that with most servers this would improve locality of reference and therefore speed. 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 also a MOVE command for IMAP, see RFC 6851=B9, but it's just an > extension since 2013 and has to be supported by both server and client > (or client's IMAP library in the case of Claws Mail, which is libetpan, > and it's not supported there yet=B2). That would be nice where avaialable > > Anyway this won't solve your problem since the server is dropping after > the command, therefore client must assume the command failed. Depending > on what was done on the server side you may also end with duplicates if > the command is reissued to cope with the server error. The last copy command is indeed potentially problematic. However unless the client library is faking up server messages the server did give me a nice refusal before dropping the connection so assuming the final copy failed would be correct in this (but not all) situations. > > Futhermore, what damage are you talking about? Have you lost any message? > Just repeating the process and deleting duplicates from the affected folder > will leave you with the process completed and no dupeas. The damage is to my mail folders which are turned into a horrific mess rather than to individual messages. The repeat and dedupe technique doesn't work if the command never succeeds as the number of messages remains higher than the number the server can cope with. In theory the damage is repairable but only with great effort. > > If the server drops the connection again may be a signal that it can't hand= > le > moving so many mails at once, so you probably need to move them in smaller > batches. Start with a small amount (e.g. 1000) and double it on each batch > That way you may find the sweet spot where the server doesn't drop the > connection and you don't have to do many batches. I tried that. It is a ridiculously inefficient use of my time. Also assumes that the point where it drops is nicely uniform. I believe that dividing the work into small batches is rightly the work of the MUA not the user and indeed claws-mail seems to agree (note splitting the move of many messages into multiple IMAP commands) but does not order those commands in the safest nor, I contend, the most efficient way. > > > [15:07:21] IMAP4> 187 UID COPY 9631:9991,9993:10028,10031:10077,10079:100= > 88,10090:10119,10127,10130:10144 "INBOX/Before2015"=20 > > [15:07:22] IMAP4< 187 NO Server Unavailable. 15=20 > > IMO this is hardly a bug and the change you suggested can still leave a copy > of a single message, hence is not more robust than current, at the cost of It would leave duplicates of multiple messages not one and would allow your repeat the command and dedupe solution to work eventually. Which I repeat it does not. In addition it would be more robust, even by your definition of the term, where the server issues a polite refusal before dropping the connection > making the whole process inefficient for non-trivial moves. There's no dama= > ge, Again I think your notion of efficiency is backwards and even using your definition you are probably wrong for most servers. > as repeating and removing duplicates can fix the server failure effects, wh= > ich > is just duplicates. Hence I'm closing this request. I disagree strongly with the word "just" for the reasons outlined. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
