[quote user="aderoy"]

Found if the folder was created first on the IMAP server then a copy the messages across (in groups of less then 2500). The larger messages could cause 'not responing' message ballons.

If the IMAP server is on a local network (100/1000) there would be problems only when the server was overloaded. Which acted similar to the FastMail situation above. This was very unlikely to happen.

[/quote]

Indeed there could be problems if moving large amount of data on IMAP. For example in my case there is a intrusion prevention system between my client PC and IMAP server - the large amount of data (or the sequence of commands who knows) triggers the Intrusin Prevention filters to drop some sessions (irrelevant of IMAP client: pegasus, thundebird - same result ). So some version of throttling or limiting the amount of data/commands per second would be perhaps desirable to avoid such things.

However - this is not the case I have described! In my case the mail move operation that initially starts on one target folder continues after moving the folder tree at a different target folder. The mails are mispalced. This is completely different and most probably Pegasus related bug, not server side bug.

Hi!

Recently I had to move a lot of mails from local mailbox to IMAP. So I had two mailboxes on my folder tree and I must admit that the list of folders is quite long - so it does not fit into the folder window.

Now I open one of the folders with a lot of messages, select all the messages and drag them onto another target folder (target is IMAP, sourde is local). Pegasus starts now moving messages, seems like one message at a time as the status line at the bottom shows that it constatly is logging into IMAP and the hourglass flickers. Its important to note that by executing copy this way the mailer is still responsive and you can do some other things like check for new mail for example or execute another similar mail moving between folders. You also can scroll the folders window - the folder tree moves but here is the real problem: this repositioning of the folder tree offsets the target folder so right after this movement the mails are moved into some other folder not originally intended. 

I tried this several times on my installation. Please note that in order to replicate this suspected bug one must have a lot of folders (or perhaps a small folder window?) and enough of mails in source folder so that the process of moving the mail is lengthy enough and one can make this trick. It's also worth to mention that I could not replicate this on my home computer then moving messages between the local folders - so I guess perhaps its somehow associated with having two mailboxes and one being IMAP? It's also important that selected mails are dragged and dropped with the mouse right onto a folder in folder tree. The same operation done with keyboard shortcuts produces different type of process where the pmail enters unresponsive state till the end of operation with the mailbox - You will not get a chance to replicate the issue.

I succeeded to mess up my mails between the folders (I executed about ten folder copy processes and scrolled the folder tree :( ) and spent a lot of time to put the things straight again. If somebody in testing team would try to replicate this and confirm that it's a general type of bug and not my peculiar setup then perhaps we could avoid others to stumble upen the same issue.

If the IMAP Server (where the folders are being copied to) is remote there can be small problems. I have found some servers (FastMail) can have problems when copying a large number (2000 plus) messages. The root cause was the DSL line combined with Fastmail timeout (even with 180 second window) - dsl is 5mb download approx 600kb upload.

Found if the folder was created first on the IMAP server then a copy the messages across (in groups of less then 2500). The larger messages could cause 'not responing' message ballons.

If the IMAP server is on a local network (100/1000) there would be problems only when the server was overloaded. Which acted similar to the FastMail situation above. This was very unlikely to happen.

If Mercury is used on the same machine or a small network (sub 10 computers)  no problem.