Andrew Daviel wrote:
If I convert a mailbox with mailutil, the "old" flags get unset,
causing all the messages to appear as "recent".
...
Hmm, looks like all the user flags are also not being copied into MBX,
i.e. Junk, NonJunk, $Label1 etc. (used by Thunderbird for
Important, Later etc.)
Mailutil says:
warning: Unknown flag: $Label1
warning: Unknown flag: NonJunk
warning: Unknown flag: Junk
You can use the "-kwcopy" flag for mailutil to copy all of these IMAP
keywords. That will not help with the problem of changing the number of
recently arrived messages. I am not aware of any way to change that.
If you copy messages to a new folder, their UIDs and the UID Validity of
the folders will change. Especially with v2006 of UW IMAP which
supports UIDPlus, this will cause all messages to be re-downloaded again
for POP users who keep messages on the server and whose POP clients use
these UIDs to track what messages have been seen.
Yes, many pop clients do track all UIDs downloaded, including the
deleted ones. This is pretty standard and correct behavior if you want
to keep pop messages on the server and not have duplicates under most
circumstances. The solution is to patch mailutil to preserve the UID
validity, UIDs, and UID next when copying. Mark has posted some patches
to this newsgroup that allow this. You can find his patch for
uid/uidnext on this maining list. Below is the patch to also preserve
UIDs (untested).
I believe Mark may be working on a tool to migrate folders "without
changes". But there is no ETA on this.
~~~~~~~~~~~~~~~~~~
For example, the following is a disgusting kludge, but it should do the
trick. You probably want to do this in a separate copy of the source
code just for this special hacked version of mailutil.
(1) Create two new global variables in mailutil.c, newuidvalidity and
newuidlast.
(2) Early in routine mbxcopy() in mailutil.c, do
newuidvalidity = source->uid_validity;
newuidlast = source->uid_last;
(3) In mix.c, prototype newuidvalidity and newuidlast as extern.
(4) In mix_create() in mix.c, change
fprintf (f,MTAFMT,now,0,now);
to
fprintf (f,MTAFMT,newuidvalidity,0,now);
(5) Finally, in mix_append(), just before the lines that read:
ret = (mix_meta_update (astream) &&
mix_index_update (astream,&idxf,LONGT) &&
mix_status_update (astream,&statf,LONGT));
add
if (astream->uid_last <= newuidlast) aastream->uid_last = newuidlast;
Define another global, newuid.
In mailutil.c, in mm_append(), just before
INIT (ap->message,mstring,(void *) ap,elt->rfc822_size); add
something like
newuid = elt->private.uid;
In mix.c, in mix_append_msg(), change:
(elt = mail_elt (stream,stream->nmsgs))->private.uid =
++stream->uid_last;
to something like:
elt = mail_elt (stream,stream->nmsgs)
if (!newuid || (newuid < stream->uid_last)) newuid = stream->uid_last
+ 1;
elt->private.uid = stream->uid_last = newuid;
newuid = 0;
~~~~~~~~~~~~~~~~~~~~~
I have not yet converted many users to mix format, but I have had
some complaints from MBX users that "old mail is being downloaded" and
"deleted mail has reappeared". So far I have:
- upgraded from imap2004 (2?) to 2006a
- added the UID patch
- transferred accounts to new hardware with more recent OS version
with rsync
- upgraded from 2006a to 2006b
One complaint was from just before the 2006b upgrade, but
I believe several days after the patch was applied. I presume these
are POP users (sometimes I hear from non-technical people in a
roundabout way days later).
I have also heard sporadic reports of continued duplicate downloads
after the 2006a + patch. I have not been able to confirm. I have also
heard of a lot of extra IMAP header downloads for some users when using
the MIX format. Also not confirmed 1st hand.
re. splitting mix boxes (so as to get benefits of smaller file size
right after conversion, rather than waiting for new mail to arrive and
users to purge old mail (ha!), I wrote something to split MBX boxes.
Ugly, but may
work for one-time mass conversion:
- split user.mbx into user.mbx.1, user.mbx.2, user.mbx.3 etc.
- mailutil copy user.mbx.1 #driver.mix/user.mix
- mailutil append user.mbx.2 user.mix
- mailutil append user.mbx.3 user.mix
etc.
I found that creating a perl script than manually does a IMAP copy
between the old and new folders for n messages at a time is also a good
way of solving this problem. I had to do that for someone who had an
almost 2Gb MBX folder with 26,000 messages in it. Made a lot of nice
little mix files (though it took some time).
-Erik Kangas
LuxSci.com
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
