thanks very much, that is helpful. Better understanding leads to fewer problems
(in life as well as software

But when you say “When a contact on one side changes, fast sync modifies the contact on the other side by overwriting all the fields that are common to both” they key question is what method does Zindus use to know which side has changed?

A simple comparison would just tell it both sides are different, and it seems like it is not keeping a full copy of each Tb record, so eg does it keep (say) a hash of each record or some other method? Apologies I am not a programmer so can’t check the source myself to understand.

This text (added to fast sync) explains what happens next:
When a contact on one side changes, fast sync modifies the contact on the other side by overwriting all the fields that are common to both (and leaving the fields that aren’t common untouched).

eg if a field (say the Work web address) is different between Tb and G, how does it know which is new and which is old (to be overwritten)? Does it keep a snapshot of the Tb addressbook? (seems likely as this is probably one of the functions of slow sync, and a reset might just delete this snapshot) Is there an indicator from G that a field has changed since some event?

1. Yes, when I create a url in the Work / Web Page, csv export / import brings them into G’s Home Page field (G has Home, Work, Home Page, FTP, Blog,…), rather than the Work field. The workaround, once I understood the problem, was to edit the csv before importing.

2. No, as I said I restored the Tb and G backups so that I was in each instance working with clean addressbooks on both sides - many times. The only non-clean item was that in Preferences (4. below) which I could also have restored but did not think it would be an issue.
From what you say the 2nd behaviour (ie 95 duplicates) is the correct behaviour on a slow sync. So I am not sure why it did not happen the first time - the imported csv was certainly the same. It seems like the behaviour that would be expected on a fast sync?? In a long sequence of testing I am bound to have done something I did not properly record.

3. Understand - but that is currently the only way to get across addresses etc. Propagating does not do it. And as I mentioned, addresses, at least for me, are fundamental.

4. thanks, agree.

My guess is that the problem some people had relates to some minor difference in a minor field (eg web page) causing slow-sync to create duplicates. The transparency you have added - saying exactly how many will be added and where - makes it easy to cancel, understand, fix then retry.

btw, A more detailed explanation of how a fast sync works would be helpful.

1. I’m not able to reproduce what you describe re: home url. When I create a contact in TB with http://home.com in the “home web page” field, then when I sync and open gmail, that contact has “http://home.com under “Website” with a “home” label. It sounds like you are seeing something different?

2. I’m guessing that the “duplicates” that got generated after you installed then uninstalled the other addon is because that other addon modified those 95 contacts in some way (eg the postal address field?). So the second time you installed zindus, it did a slow sync and couldn’t match them (because they really were different).

3. It’s playing with fire to (a) have contacts in TB, (b) export them to Google then (c) expect slow sync to match them perfectly. It sounds like it has worked for you and that’s great, but it assumes that Thunderbird’s export process and Google’s import process doesn’t transform the contacts in any way whatsoever and that’s a big assumption! As an alternative, see how to propagate contacts.

4. the reason the addon retained your account details across uninstall/reinstall is because they’re stored in preferences. To see your preferences, open Tools/Options/Advanced/Config Editor then type “extensions.zindus”. You’re probably right that an uninstall of the addon should wipe those prefs too - will file a bug for this.

Thanks for the great feedback!