New folder creation on REMOTE (DO READ)

Sebastian Spaeth Sebastian at SSpaeth.de
Tue Sep 20 17:57:20 BST 2011


On Tue, 20 Sep 2011 14:59:17 +0200, Vincent Beffara:
> 
> Hi again,
> 
> I tried a few things, and none seemed to fix my problem ... To sum it
> up:
> 
> - I am using IMAP <-> IMAP
> 
> - remote is Cyrus IMAP at work, folder names like INBOX, INBOX/math,
>   INBOX/something etc.
> 
> - local is Dovecot, folder names like INBOX, math, something
> 
> So, I have a remote nametrans that does re.sub('INBOX/',''), and all
> goes well, up to the time when I upgrade to revision fd6261a, which
> complains like this:
> 
> AssertionError: newdstname bogus equals newsrcname bogus bogus bogus

This is a leftover debug statement and it is a good thing. It means your
back-and-forth nametrans resolve to the same name :-). It also means you
are on the next branch on a commit older than
b92e453f0ea7c26c5eceebfb45083338564281e6 where this debug statement was
removed.

(it slipped in accidentally, I usually don't include stuff like this in
the code, sorry)

> Given the code in Base.py, that seems to be expected, so I move to
> revision b92e453 which is the next one. Now it complains that it cannot
> create folder 'bogus' on the remote side. Again this is expected, it
> does not conform to the remote name pattern. So I add a nametrans on the
> local side, adding 'INBOX/' in front of the names.

b92e453 also still contains a bug. which leads to wrong name
resolution. The fix is in commit b0e88622c4 as a response to yours and
Jon Wiegleys error reports, so you should be trying at least this
one. Ideally, you go directly to current next's HEAD which also honors
the remote folderfilter when determining whether to create a new folder
on REMOTE.

> Upgrading to the current 'next' branch, having a nametrans on the local
> repository or not changes nothing, it fails to create 'bogus' on the
> remote end in all cases.

Are you saying that you do see these warnings on the current next HEAD?
And you still see that "bogus" already exists warning?

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/20110920/6c9fe8e4/attachment-0001.sig>


More information about the OfflineIMAP-project mailing list