On Mon, Apr 13, 2015 at 11:59:36AM +0100, William Hay wrote: > 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.
That's not possible. IMAP clients have not a clue about how the server deals with messages. The current operations are already 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. > 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. 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. [...] > > 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. That's what I said, yes :) > > 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. That's theory also. In practice the command succeeds for a small number of messages :) But yeah, you have a crappy server, you're 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. > > 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. The work is already didived in batches, as you have seen in log. This was just a suggestion to workaround your faulty server by hand and help you to solve your problem with your server in future moves. > > > [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 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. > > 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. Well, I understand your time is also involved, but given you have a *faulty server* I think having only to invoke the duplicate removal option to fix it after a successful completion is a reasonable tradeoff, but of course you can disagree. regards, -- Ricardo Mones ~ RTFM - "Read The Manual" (The 'F' is silent). Usually a very good idea. Bjarne Stroustrup
signature.asc
Description: Digital signature
