<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 13. May 2022, at 22.17, Darren Mobley <<a href="mailto:decker@n3t.net" class="">decker@n3t.net</a>> wrote:</div><div class=""><div class=""><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;" class=""><div class="">May 13 13:28:17 dsync(<a target="_blank" href="mailto:saywhatnow@letest.tld" style="color: rgb(0, 0, 238);" data-zeanchor="true" class="">saywhatnow@letest.tld</a>): Debug: brain M: Local mailbox tree: INBOX guid=980aa92b41a37e62cd0f0000537c03e1 uid_validity=1652466497 </div><div class="">May 13 13:28:17 dsync(<a target="_blank" href="mailto:saywhatnow@letest.tld" style="color: rgb(0, 0, 238);" data-zeanchor="true" class="">saywhatnow@letest.tld</a>): Debug: brain S: Local mailbox tree: INBOX.INBOX guid=00000000000000000000000000000000 uid_validity=0 </div></div></div></div></blockquote><br class=""></div><div>So your remote has INBOX and INBOX.INBOX. This is quite special case for imapc connector and cannot be solved easily. I did hit this once at a customer when I was doing migrations for them.</div><div>This was few years a go and unfortunately I cannot remember how the problem was solved. I remember that it required TWO separate dsync runs to migrate INBOX separately and remaining folders in another run.</div><div>I wrote a workaround to the migration framework to monitor the migration logs and then apply workarounds if end user and this strange INBOX.INBOX setup.</div><div><br class=""></div><div>Unfortunately that is all I can remember about it and I've since left Open Xchange and do not have an access to my old migration toolkit bits and command line documentations.</div><div><br class=""></div><div>Sami</div><div><br class=""></div></body></html>