Uh Clem's Admin World

I had a user inadvertently delete all their email (yeah, I know).  So to fix the problem I proceeded to remove ALL deletion stubs from all replicas, including the user's local replica.  Then I restored the user's mail file from the night before to one of the clustered servers.  The clustered servers would replicate and all the server replicas of her mail file would be fine.  Once the user's workstation replicated the mail file with the server all the emails would disappear again!   My first thought was there was a second copy of the mail file on the local machine,  but confirmd there was not one.   So where could those deletion stubs be coming from?

My thought process led me to think about what other databases could be replicating data with the mail file, and then it hit me.  The local names.nsf was passing data via the "Synchronize Contacts" task, which is new in Notes 8.  Opening a PMR with IBM they assured me that ONLY contacts were being transferred.  I wasn't convinced.

So I ran a test.   I removed ALL deletion stubs out of the mail file.   Then I removed all deletion stubs out of the local names.nsf.   I used MartinScott's Noteman utility to do this.  The free version allows you to remove deletion stubs.  Then I went to the mail file and deleted 4 emails from the inbox.  I performed a replication that included the "Synchronize Contacts" task.  I went into the local names.nsf and viewed the deletion stubs.  Sure enough there were 4 deletion stubs in there with the EXACT same UNID's as the deleted emails in the mail file!!!  WHAT THE HECK??

I can find no documentation about EXACTLY what the "Syncronize Contacts" task is sharing between the mail file and the local names.nsf.  But BE WARNED,  it is at least sharing deletion info of regular emails that turn into deletion stubs in the local names.nsf that will come back to haunt you!

This might be a bug in 8.0.2.  I don't know yet.  I have not tested other versions.  My PMR is still open.  I will share my test with them and push the issue, and will blog more when I know.