Effectiveness of folder filtering, cont'd

Dave Abrahams dave at boostpro.com
Thu Jul 19 19:53:58 BST 2012


TL;DR: is there some good reason we even include filtered folders in the
       list of folders stored for each repository?  Suppose we just
       never created those folder objects in the first place?

on Thu Jul 19 2012, Dave Abrahams <dave-AT-boostpro.com> wrote:

> on Thu Jul 19 2012, Dave Abrahams <dave-AT-boostpro.com> wrote:
>
>> I just found the following in my offlineimap output:
>>
>>   BoostProRemoteReadOnly:INBOX -> BoostProLocal
>>
>> What's baffling about this is that the BoostProRemoteReadOnly
>> repository had the following settings:
>>
>>   folderincludes = ['[Gmail]/All Mail']
>>   idlefolders = %(folderincludes)s
>>   folderfilter = lambda foldername: False
>>
>> Which, as far as I can tell, *ought* to prevent it from syncing INBOX
>> from there.  Am I missing something about how this is supposed to work?
>
> Update:
>
> Having trolled through the code, I see that folderincludes doesn't
> *necessarily* work as advertised.  At least, if you put something in
> folderincludes that was seen, but ruled out, by folderfilter, the same
> folder will appear twice in the list of folders, once with sync_this set
> to False and again with it set to true.  That seemd suspicious, so I
> switched to a more traditional setup that used only folderfilter and no
> folderincludes:
>
>   idlefolders = ['[Gmail]/All Mail']
>   folderfilter = lambda foldername: foldername in %(idlefolders)s
>
> But unfortunately, it didn't seem to cure the problem:
>
>  Syncing INBOX: Gmail -> MappedIMAP
>  Copy message 65245 (1 of 3) BoostProRemoteReadOnly:INBOX -> BoostProLocal
>  Copy message 65246 (2 of 3) BoostProRemoteReadOnly:INBOX -> BoostProLocal
>  Copy message 65247 (3 of 3) BoostProRemoteReadOnly:INBOX -> BoostProLocal
>
> I have two repositories talking to the same IMAP server and account.
> BoostProRemoteReadOnly is supposed to deal with the "All Mail" folder
> and BoostProRemote is supposed to deal with INBOX.  Could that be
> related to the issue?
>
> Hmm... looking further, the only place that a /local/ folder's sync_this
> flag is checked is in accounts.syncfolder(), which is only used, AFAICT,
> by idle support.  It's called in one place, by
> imapserver.IdleThread.dosync().  Shouldn't the remote folder's sync_this
> flag be checked as well before allowing such a sync to proceed?  And
> shouldn't the local folder's sync_this flag be checked for ordinary
> (non-idle) syncs?
>
> I just added some code to look for that case; we'll see if it prints a
> warning and/or makes any difference.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com





More information about the OfflineIMAP-project mailing list