[PATCH 4/8] Re: Create new folders on srcrepo if needed

[Sebastian Spaeth]

On Sat, 3 Sep 2011 15:10:45 +0200, Nicolas Sebrecht <nicolas.s-dev at laposte.net> wrote:
> On Mon, Aug 29, 2011 at 04:00:13PM +0200, Sebastian Spaeth wrote:
> 
> > This will ignore any nametrans rules, so we might want to limit this
> > only to cases where no nametrans has been specified,

> I guess this behaviour would be very confusing for most end-users. I'm
> not sure to understand everything myself.
> 
> Since you start ignoring nametrans rules, we do want (not might) to
> limit to cases where no nametrans has been specified.

My commit comment is obsolete and wrong, actually. The correct behavior
has been specified in the code source:

   +        nametrans rules
   +        in both directions will be honored, but there are NO checks yet
   +        that forward and backward nametrans actually match up!
   +        Configuring nametrans on BOTH repositories therefore could lead
   +        to infinite folder creation cycles."""

So, if we have on REMOTE:
 nametrans = lambda x: "INBOX." + x
and on LOCAL:
 nametrans = lambda x: "foo." + x

a local folder "Sent" would be created on remote as "foo.Sent". On the
next cycle "foo.Sent" would be created on LOCAL as "INBOX.foo.Sent"
etc. :-) But this is actually a user configuration error as "forward"
and "backward" nametrans rules need to match, eg. this would be correct

REMOTE:
 nametrans = lambda x: "INBOX." + x
LOCAL:
 nametrans = lambda x: re.sub('^INBOX.', '', x)

> Some thoughts:
> 
> - do the remote folder creation _only if_ nametrans applied on it
>   doesn't change the local folername. This use case looks to be based on
>   a wrong assumption of what the created folder on remote will appear to
>   the client on next run.

That would be an option, right.

> - do the remote folder creation, fetch the new list of folder, apply
>   folderinclude on it, apply nametrans on it, apply whatever is needed
>   to have the name we'll have on next run, check that the final local
>   foldername matches the original local foldername:
> 
>     - if they match: accept the creation.
> 
>     - if they don't match: refuse and delete the remote foldername, or
>       rename/move the original local foldername to match the resulting
>       foldername.

> Not sure. I agree if you're saying "we might want to use the nametrans
> setting /on/ the /newly created/ dest repo".
> 
> Or, I misunderstood. :-/

I think I meant we should configure and behave the way we do now. What
we can actually do to improve is to use a safeguard as you propose
above:

- We actually apply the nametrans rules in both ways and see if we end
  up with the same folder name, if yes we are fine, if not there is a
  misconfiguration.
  I think that is easy and feasible and we can warn the user about it
  preventing her from shooting herself in the foot. But we can merge
  this one first and put the safe guard in as a separate topic.

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/20110905/ca4f8c56/attachment-0001.sig>