Locally created mailboxes not synchronized to IMAP
d.s at daniel.shahaf.name
Tue Aug 9 16:10:26 BST 2011
Vladimir Marek wrote on Tue, Aug 09, 2011 at 12:26:11 +0200:
> thanks for the review!
> > 1) It would be great to split out white space changes and functional
> > changes into separate patches, as it makes reviewing the patches much
> > harder. (OK, enough nitpicking :-))
> That's right. I'll surely do some cleanup, it was just current state
> snapshot to show my intentions.
> > 3) Creating (and deleteing) new folders on both sides would be trivial
> > if it were not for 2 things: folderfilters and nametrans. Both make
> > things more complicated.
> I understand that now. Indeed I overlooked those.
> > nametrans is the tougher one. It is 1-way fudging of names and as you
> > remark you would need a corresponding "nametrans" setting on the local
> > repository that reverses names exactly. Given the difficulties of
> > setting up correct nametrans rules (often including horrible regexes),
> > it will be *very* difficult to find the exact reverse functions. I would
> > be more comfortable to have something like this after we introduce a
> > "--dryrun" option that allows to see what offlineimap would do when it
> > would actually be run.
> > For now I would be happy to have patches that enable folder creation
> > only when nametrans is not being used.
> Suppose we have two namentrans functions (nomral and reverse). For each
> folder we can check that they give 1:1 mapping. Just pass any folder
> name to be created or deleted through normal and the result through
> reverse (or vice versa for the other direction) and see if we get the
> same result. If not, don't do anything destructive and tell user to fix
Or, instead of requiring a reverse mapping, just generate it dynamically
from the nametrans mapping: every time nametrans is called, store the
original and mapped name in a data structure. (A list of tuples, or
a dict keyed by the mapped name.) Assuming people don't have
a six-digit number of folders this should be reasonable...
> his config. To me this should not create any risk to user and he does
> not need --dryrun and checking if nametrans is in use. Surely those are
> valid options too.
is more common.
More information about the OfflineIMAP-project