mbnames

[Sebastian Spaeth]

On Thu, 19 Jan 2012 11:50:45 +0100, Thomas Kahle <tomka at gentoo.org> wrote:
> OK, --info is good.  I see what's going on.  I need to pass both
> translated foldername and untranslated foldername to -f to make it sync.
> This raises the question how the folderfilter should work.  If I do -f
> INBOX, should it sync only from INBOX (which is the remote name) to the
> local copy or bidirectional?  I find this very confusing.

Ugh, the way things are currently implemented is that the -f option
operates as a folderfilter on the remote repository, ie it operates on
the untranslated REMOTE names.

ie, if you specify -f INBOX, it effectively sets the remote folderfilter
rule to "lambda f: f in ["INBOX"]"

> Also, the usage of "translated" is completely ambiguous now.
> Offlineimap translates foldernames back and forth--both are translated.
> It should be called local-alias and remote-alias and 'nametrans' should
> be 'produce-remote-alias' and 'produce-local-alias' (or something along
> these lines).

Yes, it was always (even back in those days) unclear on which repository
nametrans rules were supposed to be put and how they worked. Now that
they are specified both ways, I need to update the documentation on that
and explain how exactly they work and *are supposed* to work.

> $ offlineimap -o -a ABC -f INBOX --info
> Remote repository 'RemoteABC': type 'IMAP'
> folderfilter= lambda f: f in ['INBOX']
> Folderlist:
>  INBOX -> abc
> Local repository 'LocalABC': type 'Maildir'
> folderfilter= lambda f: f in ['INBOX']
>  abc -> INBOX (disabled)

Uggh, have you specified the 
folderfilter= lambda f: f in ['INBOX']
line on the local repository in the config file or does that come from
the -f option as well? -f is only supposed to modify folderfilter rules
on the remote repository.

No, looking at your examples I can see that any folderfilter rule you
specify with -f is being reported for *both* the remote AND the local
filter rule, which does not really make sense at all. I will need to
explore what really happens there.

The --info output was helpful, thanks.

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20120120/b8e115a1/attachment-0001.sig>