Oswald Buddenhagen on 2016/02/05 +0100 @09:47:05:
> On Thu, Feb 04, 2016 at 02:43:50PM -0800, Scott Mcdermott wrote:
> > Getting this nearly every time I sync my local Maildirs with
> > Google's IMAP server:
> >
> > Maildir notice: sleeping due to recent directory
> > modification.
>
> i suppose that may mean that you're syncing folders multiple
> times directly adjacently. maybe your Patterns are botched? ...
> try mbsync -l, possibly in combination with -DMn ...
Thanks, that was the needed info. It turns out I was fetching
INBOX twice, in two different channels. That's why it was
running so close in time and hit the timestamp check. The
program could possibly keep track of (mailstore, folder) tuples
it has seen already and issue a warning or halt if it sees the
same tuple twice, in order to avoid this.
If you're curious how this happened: what I'm doing is mapping
the Gmail special folder names to local ones that are my own, by
making separate channels for each one, such as:
Channel gmail-sent
Master :imapsrv:"[Gmail]/Sent Mail"
Slave :maildir:sent
Channel gmail-postponed
Master :imapsrv:"[Gmail]/Drafts"
Slave :maildir:postponed
...
and so on. Then to get the rest of the folders, which already
have my preferred labels (since I control them with delivery
rules on the server) so I don't need to map them:
Channel gmail-user-labels
Master :imapsrv:
Slave :maildir:
Pattern *
Pattern ![Gmail]/*
Pattern !sent !postponed !saved !spam !trash !spool
(note the exclusions needed, since I already matched those with
the previous specific mapped channels above.)
I also made a separate channel for Inbox, because, even though my
Inbox did live under Path on the local side (and thus was globbed
by the 'Pattern *'), I didn't want to get caught later if it was
ever somewhere else not within Path, so I made a separate channel
with no pattern to match just INBOX:
Channel gmail-inbox
Master :imapsrv:
Slave :maildir:
and tried to exclude it in 'gmail-user-labels' channel with its
mapped name, ie by '!spool' (which doesn't actually match btw,
presumably because the 'Inbox'-provided name isn't part of the
"mailbox list from slave").
What I did not realize was that patterns have to be excluded
twice (as they match on both Master and Slave side), because of
this misleading text from the manual's description of Pattern:
The mailbox names are the same on both Master and Slave
(In fact, they can be completely different names if they are
given explicitly in the channel definition as I'm doing, and also
by using the 'Inbox' directive.)
Anyways, it seems to work correctly now, after adding '!INBOX', I
have only the 'gmail-inbox' channel matching it now. I have not
seen the warning since adding that exclude pattern to my
'gmail-user-labels' channel (so far).
> the purpose of the check is to ensure that we have an atomic
> snapshot of the mailbox, which is important when messages get
> moved between the cur and new subdirectories (failure to do so
> would produce a double listing and subsequent UID clash and
> error out, or no listing and a resulting bogus propagation of a
> deletion and thus data loss).
Indeed, but atomic reads at mailbox level with Maildir are not
actually possible, so this sleep check could loop for a while
(potentially forever) if the Maildir is busy being changed by
other software.
(Actually, my understanding is that getdents64(), if used
directly, can give all the dirents atomically if provided with a
big enough buffer, but readdir() is required for portability of
course.)
--
Scott
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
