Hi Pierangelo,
contextCSN: 20080727021429.070493Z#000000#000#000000 contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA==
which looks like
4 bytes of garbage + "0802033718.300111Z#000000#001#000000"
Yes, but I would like to bring a precision : under VI the 4 bytes are handled as 2 characters only. In fact each time the problem occurs I repair my database using a BDB C program wich reads the first key from id2entry.bdb and writes it on disk. Then I use vi to fix the contextCSN, before writing the key back to the database. Using vi I do not delete any characters. I only replace them by 20, then I fix the rest of the fields.
Another precision : when the first two chars take corrupted, the rest of the contextCSN gets stuck and does not follow write operations.
I note that, according to the sid values you assigned to servers A and B, the first contextCSN should not appear, since it has sid == 0, while the second one, apart from the corruption, is plausible (as you're writing to server A, with sid == 1).
Yes. The contextCSN with sid=0 is there because at the beginning I initiated my directory without SID (defaults to 0), then I set two difrent SIDs for A and B.
Best Regards Ali