On Sat, 2015-09-05 at 13:53 +0200, Guillem Jover wrote:
> Hi Ian!
>
> On Fri, 2015-09-04 at 10:38:09 +0100, Ian Campbell wrote:
> > On Tue, 2015-07-28 at 09:21 +0100, Ian Campbell wrote:
> > > I'm suffering from a similar issue to Guillem,
>
> > I had a realisation which might be useful to you as well: The
> trailing "/"
> > on a store:mailbox is (or can be) significant, e.g. the following
> diff
> > against my previous redacted mbsyncrc appears (on first glance) to
> work and
> > to do what I desire:
>
> > The change to Master being the primary thing. This results in the:
> >
> > [Account]
> > |-INBOX
> > |- PATCHES
> > | |- WIP
> > | `- FOO
> > `- Cronspam
> >
> > maildir hierarchy which I noted in Message #75 I'd be happy to
> switch to if
> > necessary.
>
> Right, and thanks for the update, unfortunately that's not a conformant
> Maildir++ layout,
FWIW the disk layout which Evolution displays as above is:
Maildir/{cur,tmp,new} # AKA "INBOX"
Maildir/.PATCHES/{cur,tmp,new}
Maildir/.PATCHES.WIP/{cur,tmp,new}
Maildir/.PATCHES.FOO/{cur,tmp,new}
Maildir/.Cronspam/{cur,tmp,new}
Just mentioning for clarity in case you thought it was:
Maildir/{cur,tmp,new} # AKA "INBOX"
Maildir/PATCHES/{cur,tmp,new}
because I thought the first (with the dots) _was_ compliant Maildir++.
> which is what I'd like to have on my client system to
> match the filesystem layout of my server system.
I can see why you might want that (orthogonally to whether the single .
prefix is valid Maildir++ or not).
> > NB: I'm still tinkering with things, so I'm not 100% sure this is correct,
> > but on first glance it looks so and I'm also not sure if it is applicable
> > to the issue in your context but I hope it turns out to be helpful!
>
> I've not had time to look into this again, but once I do, I guess I'll
> try to prepare a patch, post it here, and if it gets rejected run with
> a local fork. Either that or try to discover how to properly configure
> the program to do what I want, in case it is really possible. :)
