using imapsync and altnamespace?

[Bill Kearney]

> Bill, I ran into this problem with one of these
> imapsync/mailutil/mailsync utilities, and what I wound up doing was, I
> sucked the mail over to a dummy folder, then manually copied the
> messages up, reconstructed the inbox, and then deleted the dummy folder.

Which won't work very well considering I'm moving a mailbox that's got
nigh-on a decade worth of mail and hundreds of nested folders.  Were it a
simple drag-and-drop I'd have gone that route.  But no GUI clients offer
decent drag-and-drop of entire hierarchies, let alone with the ability to
ignore/continue when errors crop up.

Thus going with imapsync or mailsync seems to be the more effective
solution.  I've managed to get imapsync to move things across but not
without a fair number of errors.  The trouble is there's not relatively
simple way to get a grip on what's causing the errors in a way that'll lend
itself to easy managing.

Thus far the magic incantation for imapsync seems to be:

imapsync --noauthmd5
    --host1 sourcehost --user1 srcuser \
    --passfile1 .pass1 --include '^mail' \
    --host2 desthost --user2 destuser
    --passfile2 .pass2
    --regextrans2 's/^mail\.//'
    --syncinternaldates

Where I'm pulling folders starting with 'mail' from the arcuser at sourehost
mailbox and then pushing them into folders on the the destuser at desthost
while removing the 'mail.' prefix from them, along with making sure desthost
dates match up with those on the srchost; using plain text authentication
for the connection. Whew.

The downside is the final report:

++++ Statistics ++++
Time                   : 20202 sec
Messages transfered    : 120788
Messages skipped       : 12465
Total bytes transfered : 934257544
Total bytes skipped    : 104881890
Total bytes error      : 7828056
Detected 1450 errors

I've yet to decide how to determine what didn't get moved.  But hey, only
1450 out of 120k ain't terribly bad.

The only other problem is it doesn't appear to be pulling the
/var/spool/mail/srcuser "INBOX" folder.  Not a big deal as I can run another
sync to handle that one, or even just use simple drag-and-drop.  I really
question the sanity of how uw-imap allows for browsing ~/ as part of the
IMAP tree, it's really a pain in the ass to work around sometimes.  I'm sure
it's useful for "someone" but I've always found it to be a lot more trouble
than it's worth.

So does anyone know *for sure* how the --delete function will behave using
imapsync?  Does it only delete that which it confirms was successfully
transferred?  If so then I could use that to determine what to do based on
what got left behind.  But before I turn it loose with the delete option I'd
sure like to avoid having to reload it all again...

-Bill Kearney