[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