Why do we need to run reconstruct after having moved mailboxes using cyradm's xfer command?

[Binarus]

Dear all,

yesterday, I have moved a bunch of user mailboxes and public folders from a server running 2.4.16 to another server running 2.5.10, using cyradm's xfer command (see my previous messages).

After having finished the migration, I noticed a weird behavior in Thunderbird (which is our standard email client): When trying to move a message from the Inbox to the Junk or Trash folder, the message disappeared from the Inbox for a short time, then reappeared. The log files on the server were showing the dreaded entries:

Dec 16 01:12:59 morn cyrus/imaps[14914]: Fatal error: Internal error: assertion failed: imap/mailbox.c: 2850: !message_guid_isnull(&record->guid)

"Fortunately", a lot of other users are affected by such log entries and weird email client behavior as well, so finding the solution on the 'net was not too difficult: Running reconstruct did not lead to anywhere, but running reconstruct -V max was the solution.

This lets me scratch my head:

In the past, I have upgraded Cyrus imapd at least three times, each time using imapsync (instead of cyradm's xfer command) to move the mailboxes and the public namespace (including all messages and subfolders) from the old server to the new one. In none of these cases, it was necessary to reconstruct anything afterwards. This would have been illogical anyway: Each time, the new server had been setup from scratch, and no mailboxes / messages / folders / subfolders had been moved directly via file transfer from the old to the new server.

Now that I have used cyradm's xfer command to relocate the mailboxes / messages / folders / subfolders, I surprisingly had to run the "heaviest" form of reconstruct (-V max).

Could anybody please shortly explain why? What exactly are the techniques and mechanisms cyradm's xfer uses to do its thing? I had been quite sure that it just uses the IMAP protocol, but there seems to be more to it ...

Thank you very much for any insight,

Binarus