1 files changed, 106 insertions(+), 0 deletions(-)

A content/blog/2022-11-21_mbsync_near_side_box_cannot_be_opened.md

@@ 0,0 1,106 @@
+---
+title: "mbsync: near side box cannot be opened and far side box is not empty"
+date: 2022-11-21
+---
+
+[mbsync](https://isync.sourceforge.io/) (project name isync) is a great tool to [synchronise mails locally to your computer](https://drewdevault.com/2021/05/17/aerc-with-mbsync-postfix.html), and one that I wrote a [blog post](https://edd.salkield.uk/blog/deduplicating_your_mbsync_maildir.html) about recently.
+However, managing your emails manually means that occasionally you'll run into synchronisation issues.
+The issue at hand today is trying to delete a mail box that still contains mail, which for safety reasons mbsync tries to prevent.
+
+Here's the setup: you delete mail box `box_name`, while it still has mail inside it.
+You use the `--remove-far` option to propagate the deletion, but experience the following error:
+
+```
+$ mbsync --remove-far channel_name
+C: 0/1  B: 9/11  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
+Warning: channel channel_name: near side box box_name cannot be opened and far side box box_name is not empty.
+C: 1/1  B: 11/11  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
+```
+
+This is because mbsync prevents deletion of non-empty mailboxes.
+See the man page:
+
+```
+man mbsync
+...
+Remove {None|Far|Near|Both}
+      Propagate mailbox deletions [to the far/near side].
+      ...
+      Note that for safety, non-empty mailboxes are never deleted.
+```
+
+There isn't a way to override this behaviour.
+The process we therefore need to follow is, in brief:
+
+* Re-create and fetch the missing mail box locally
+* Delete the offending mail locally and resynchronise
+* Delete the mailbox itself and resynchronise
+
+#### Re-create and fetch the mail box locally
+
+We firstly need to recreate the local mail box which is missing.
+According to the maildir spec, this consists of one parent `box_name` directory, with three children: `cur`, `new`, and `tmp`.
+
+```
+$ cd ~/mail
+$ mkdir box_name/cur box_name/new box_name/tmp
+```
+
+When you resynchronise, the a new UIDVALIDITY will be created.
+This is a unique ID that identifies the mailbox between renamings.
+However, if the old UIDVALIDITY is still in the cache, mbsync will detect a change and error.
+For example:
+
+```
+$ mbsync -a
+...
+Maildir notice: no UIDVALIDITY, creating new.
+Error: channel channel_name, near side box box_name: Unable to recover from UIDVALIDITY change.
+C: 1/1  B: 11/11  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
+```
+
+So we can remove that box from the local cache:
+
+```
+$ mv ~/.mbsync/:remote_channel_name:Starred_:local_channel_name:Starred /tmp
+```
+
+And then fetch the mail locally:
+
+```
+$ mbsync -a
+henleybeach:~$ mbsync -a
+C: 3/3  B: 23/23  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
+```
+
+#### Delete the offending mail locally and resynchronise
+
+Now we can delete/move the mail locally.
+You can do this in your mail client, or alternatively just by removing the contents of the mailbox yourself:
+
+```
+$ cd ~/mail
+$ rm box_name/cur/* box_name/new/* box_name/tmp/*
+```
+
+Now we must re-synchronise, making sure to remove the emails on the far side with the Expunge option.
+This can be set in the config file, or overridden with the command line as follows:
+
+```
+$ mbsync -a --expunge-far
+```
+
+#### Delete the mailbox itself and resynchronise
+
+Now the far side has dropped the mail, it's safe to remove the mailbox:
+
+```
+$ cd ~/mail
+$ rmdir box_name/cur box_name/new box_name/tmp box_name
+```
+
+We resynchronise for a final time, removing the far box:
+
+```
+mbsync --remove-far -a
+```