Fwd: [Sebastian Spaeth: Re: [ANNOUNCE] OfflineIMAP v6.4.0]

[Daniel Shahaf]

Forwarding back to the list (with permission), adding my responses inline.

----- Forwarded message from Sebastian Spaeth <Sebastian at SSpaeth.de> -----

> Date: Fri, 30 Sep 2011 10:16:04 +0200
> From: Sebastian Spaeth <Sebastian at SSpaeth.de>
> To: Daniel Shahaf <d.s at daniel.shahaf.name>
> Subject: Re: [ANNOUNCE] OfflineIMAP v6.4.0
> Message-ID: <871uuy5ttn.fsf at SSpaeth.de>
> 
> On Thu, 29 Sep 2011 23:45:14 +0300, Daniel Shahaf <d.s at daniel.shahaf.name> wrote:
> > Daniel Shahaf wrote on Thu, Sep 29, 2011 at 20:31:28 +0300:
> > > On the other hand, in an account that does use nametrans, I didn't add
> > > any new nametrans's to the config, and I don't see any warning or error.
> > > Is that expected?  Will there be any ill effects, other than perhaps not
> > > creating folders on the remote side?
> > 
> > Well, it didn't remove the UNSEEN flag on the remote end.  I then added
> > the nametrans, but that caused offlineimap to start re-uploading ALL
> > local messages to the remote end (even in folders that haven't changed
> > in days).
> 
> Uuhh, ohh. If a remote folder has a corresponding local one (based on the
> remote nametrans rule) things should work just fine and as they have
> done before. Local nametrans rules are only ever checked and required if
> you find a local folder that has no corresponding remote one based on
> the remote nametrans rule.
> 

The nametrans rules are:

local:  nametrans = lambda localfoldername: 'INBOX.' + localfoldername
remote: nametrans = lambda foldername: re.sub('^INBOX\.', '', foldername)

Previously only the 'remote' nametrans was present.  (Given your
response, I have now unadded the local nametrans setting, too.)  I have
also verified (via an IMAP/telnet session) that all folders in that
account are subfolders of INBOX, and that INBOX.INBOX type folders do
not exist.

> > I've therefore reverted to the v6.3.4 tag.  It repeated the 10 or so
> > re-uploads that v6.4.0 did, but otherwise seems to be acting normally.
> 
> My latest next branch has the server diagnostics enabled again, which
> will output information on how folders will be mapped.
> Does an --info on that leads to useful output (it won't perform any sync
> then)

I cannot check this now, but later I will try --info with the latest
spaetz/next branch and report back.

> 

Thanks!

Daniel


----- End forwarded message -----