mbsync: near side box cannot be opened and far side box is not empty


mbsync (project name isync) is a great tool to synchronise mails locally to your computer, and one that I wrote a blog post 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 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, 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

Articles from blogs I read

In praise of Plan 9

Plan 9 is an operating system designed by Bell Labs. It’s the OS they wrote after Unix, with the benefit of hindsight. It is the most interesting operating system that you’ve never heard of, and, in my opinion, the best operating system design to date. Even …

via Drew DeVault's blog November 12, 2022

Do I still remember how to blog?

I haven’t written a blog post for a couple of months now, which is a good indicator I should probably document my workflow before I forget how to do it…

via Not Just Serendipity October 9, 2022

Github Copilot: The future of programming?

My thoughts on GitHub Copilot and the future of AI assistants in writing code.

via Josh Smailes April 15, 2022

Generated by openring