[MlMt] Moving to a new computer
Bill Cole
mmlist-20120120 at billmail.scconsult.com
Sun Dec 9 11:19:17 EST 2018
On 9 Dec 2018, at 8:24, Benny Kjær Nielsen wrote:
> On 6 Dec 2018, at 18:26, Bill Cole wrote:
>
>> On 6 Dec 2018, at 11:36, Robert Brenstein wrote:
>>
>>> Benny or anyone else…
>>> Why should we copy just the plists and prefs and refetch all the
>>> mails? If I follow the recommendation below, that what we should do.
>>> However, with 100k mails in dozen IMAP accounts, this will take a
>>> while. I would rather copy the entire MailMate folder from the
>>> Application Support and com.freron.MailMate.plist from Preferences
>>> to another computer. Direct copy is fast.
>>
>> I tried that. It was ugly, because I used 'rsync' without the flag to
>> replicate extended attributes, which MM uses to store a message UID.
>> I was fortunate to have been watching how the whole process worked...
>>
>> So *MAYBE* you can make it work but you should make absolutely
>> certain that you replicate extended attributes and when you fire up
>> MM afterwards, WATCH what MM does and be prepared to kill it and work
>> out any issues you have.
>>
>> I can't imagine Benny recommending mail cache replication, given the
>> risks that it carries.
>
> To be honest, I hadn't really considered this problem case. Just for
> the record, I believe it should still work without these UIDs, because
> they are also stored in the database index files. The main purpose of
> the attribute is to help MailMate *if* it has to rebuild its database
> at a later time.
The problem I had was that MM did not see the message files in the cache
that lacked a UID attribute as being the same message as the originals
that were still on the server. It also refused to allow the deletion (or
"reset") of the no-UID cached messages.
--
Bill Cole
More information about the mailmate
mailing list