Menu
▾
▴
#83 Path cannot be nested under Inbox
I upgraded isync in debian/trixie and suddenly I'm getting many errors I don't understand:
When I run mbsync <channel> I'm told: Path cannot be nested under Inbox
My .mbsyncrc contained:</channel>
MaildirStore local
Path ~/Maildir/
MapInbox Inbox
I got rid of that message by adding an Inbox line:
MaildirStore local
Path ~/Maildir/
Inbox ~/Maildir/
MapInbox Inbox
However, now I have another error:
Maildir warning: ignoring INBOX in /.../Maildir/
Error: channel ...: far side box INBOX cannot be opened.
I made a couple of experiments that didn't work, like removing a slash and writing
Inbox ~/Maildir or writing Inbox ~/Maildir/Inbox orInbox ~/Maildir/INBOX``, but they didn't work (and I have no mailbox named explicitly Inbox nor INBOX). Before todays upgrade mbsync worked without problems and its been 12 years. Recommendations?
first you should make sure that you actually understand what Inbox and INBOX are. then you can assess how this relates to your actual setup, and from there determine how to fix or simply suppress the problem. you probably also shouldn't be using MapInbox.
useful diagnostic steps are running
mbsync -lsand latermbsync -l -a, but that might require at least suppressing the issue at first.if you need further assistance, attach your config and the output of the first command.
Hi,
Thanks for your answer.
I configured my mbsync more than a decade ago, so you're right that I
don't actually understand what Inbox and INBOX are or ought to be. In
my local machine I have a ~/Maildir/ directory with its usual cur/
new/ tmp/ subdirectories, and that is my actual inbox, where I receive
nuew mail. Furthermore, I have many subdirectories, such as mbox,
mbox2023, mbox2023... where I write emails I have already
processed. In my configuration I have a couple of channels to either
synchronice all my email with my remote server or only a few of
them. I understand that I need MapInbox to be able to include Inbox
explicitly in that list of boxes to synchronice.
My configuration is (edited the password and the comments):
The output of mbsync -ls em is
If I run mbsync -ls without further arguments I get the error:
$ mbsync -ls
Maildir warning: ignoring INBOX in /home/mochan/Maildir/
Maildir error: found subfolder 'INBOX/mbox2006', but store 'emlocal' does not specify SubFolders style
and then it seems the program hangs, so I interrupted it
^C
The output of mbsync -l -a is
Currently, mbsync seems to synchronize correctly my mail boxes, except
for the error messages I receive about INBOX. But I can't get it to
work without adding the Inbox line to my configuration.
Thanks and best regards,
Luis
Last edit: Oswald Buddenhagen 2025-03-11
yeah, that config won't work anymore, because it's incoherent.
however, you can adjust the config to actually match the physical layout. you only need to make it more similar to the other store: unset Path and MapInbox, set
Inbox ~/Maildir, andSubFolders Verbatim. then adjust the Patterns to the resulting new layout. make sure to test with -ls and -l before you run an actual sync, as otherwise you'll get duplicate boxes if something doesn't match.the hang is definitely a bug, so keep a copy of your broken config, to be able to repro it at will. for starters, add -D to the hanging command and attach the output.
the results of mbsync -ls -D before updating my .mbsyncrc:
Last edit: Oswald Buddenhagen 2025-03-11
ok, thanks. looks like i just failed to wire up the error cleanup path callbacks properly.
Question: After following your suggestions above for the local store, mbsync -ls shows my local store has boxes such as INBOX, INBOX/mbox, INBOX/..., while in the remote store I get INBOX, mbox, ... (without INBOX/ preceeding the names of the other boxes). If I remove MapInbox from the remote store config the results look similar (i.e., I get INBOX/mbox in the local store but just mbox in the remote store). Thus, what should I put in patterns? Something
Pattern INBOX INBOX/mbox% ...orPattern INBOX mbox% ...? I guess that INBOX should be all in uppercase, right? Should I do other changes before actually attempting to synchronize?By the way, with the new config mbsync -ls doesn't hang.
mbsync -l -a complains that my local store has no Path
you probably need something like
hmm, indeed, Path cannot be omitted with
SubFolders Verbatim. that's actually kinda a bug. just set it to something useless like ~/tmp.Hi. Before trying your full suggestion I made one of the new channels
using the emlocal store you suggested before but specifying just one Pattern to test
adding an empty directory as Path, and made a dry run of mbsync with the new configuration for just this channel
I interrupted with a ^C.
The dry run was not dry and the system began copying the first of 6K+ messages under the directory specified in Path. What I would expect is the configuration to have recognized that I already have a mailbox ~/Maildirs/mbox and that it was up to date.
but did it actually copy anything? the dry run is intentionally very thorough in pretending that it does something. adding -Dd will show what is actually happening.
It did. If I run with -Dd and -y it doesn't, but if run with -y it does:
So, using
-y -Ddthe program wrote what it would do and the directory mentioned in Path was left alone, but only using-yit started copying until it was interrupted and the directory started growing.The output from
mbsync -c mbsyncrc_new -y -Dd -V ems >rem.txtis attached belowoh, right, now that you mention it, it's totally obvious: the "drying" is implemented in the proxy driver which implements -Dd. fix upcoming ...
i believe the -ls hang and the ineffective --dry-run to be now fixed in git master.
Great!
I still wonder about my configuration. I guess part of the problem is due to using different formats in my mail server (with dots) and in the client (with subdirectories). I haven't attempted a non-dry run with the configuration you suggested, but I don't want to saturate my laptop's disk with copies under 'Path' of emails I already have elsewhere. My current (incoherent) configuration seems to work, except for the error messages about non-existing Inboxes in the client and the server. Any further advice will be very appreciated
well, the dots on the server are just directories as far as isync is concerned, provided the server tells it so according to spec.
just try the new config with
-l. if it's still wrong, you need to look at your paths and-lsoutput again. if you can't make sense of it, attach the outputs and the updated config.I don't know if it is correct. Locally I expected INBOX/mbox (see below)
Seems correct, except for the funny INBOX/INBOX, mboINBOX, etc, which must have been created while doing tests but are empty. (I wonder if I can simply remove the corresponding directories).
However, when I make a dry run:
So it seems the system would try to fetch my whole INBOX, although it is mostly synchronized with my server. The configuration file I'm using is:
If I use a slash instead of a dot after INBOX in the channel emSin then
mbsync -c... -lrespondsmbox <=> INBOX/mbosbut the rest is the same, and it would still want to fetch my complete inbox.whoops, yeah, it obviously should be
Near :emlocal:INBOX/.yes, you can (and should) delete the bogus folders. as you're not using
SyncState *, you should also clean out corresponding state files from the sync state directory.ah, the SyncState thing is also why it wants to fetch the inbox from scratch - the logical folder names changed, so the state file names don't match anymore. you can simply rename them to match (considering that
/is translated to!), but i would recommend that you actually switch toSyncState *and move the files into their respective local folders as.mbsyncstate.I guess I will make a couple of dummy accounts before testing that. However, I found I made an erroneous interpretation: The 6K+ messages that mbsync would fetch are from mbox, not from INBOX. The outputs of mbsync -l are
I also tried to change Path to a link to Maildir, but it didn't work so I reverted my new configuration to the previous one. I don't know what else I could have done, but now mbsync with the new configuration tells me it would pull 6K+ messages but also that it would push 6K+ messages. I recall previously it wanted to pull them, but not to push them.
the mapping looks just fine, no?
that it wants to both push and pull is a classic indication that no sync state is present (or has been found, in your case).
testing this with dummy accounts seems rather pointless, as that will just sync from scratch anyway. then you can just throw away your maildirs and sync state, and start afresh.
so just move the sync state files in place and try with -y (preferably after you install git master).
cp -althe local store somewhere, just in case.as there were no further followups, i'm assuming that the configuration issue was resolved.
i had a quick look at the code checking that Path is configured, and found that it should be triggered only if Path is actually referenced somehow, f.ex. via a Pattern. so i'm assuming that this issue was part of the bigger misconfiguration. please post a minimal reproducer if that is incorrect.
I'm sorry; kind of short of time, so I returned to the configuration I showed above on 2025-01-26. The system has continued working but for the warnings
I haven't understood yet the situation, but my inboxes in the remote and local machine and my other mailboxes are being correctly synchronized.
Last edit: W_Luis 2025-03-11
you should cut it down to what is actually needed. if some weirdness persists at this point, we can investigate.
This is my current mbsyncrc:
When I use it I get the message:
with different sets of numbers, but my inbox and the other two mailboxes are correctly synchronized.