[gmane.mail.imap.offlineimap.general] Re: [PATCH] Re: Avoid trying to synchronize folders that have empty names

[Sebastian Spaeth]

Dodji Seketeli <dodji at seketeli.org> wrote:

>Hello Sebastien,
>
>I haven't had any reply from you to the message I sent to the
>offlineimap development list, but then I realized I haven't CC-ed you
>specifically.  So I am forwarding you the message I sent, just in case
>you don't read the list actively.

Sorry, due to work-related stress I currently don´t keep up with the list.

>I have no nametrans rule.  I do have cur/new/tmp in the top-level.  But
>they are empty, because the only maildir folder that actually contain
>emails are in sub-directories of the top-directory.  After looking
>closely, I realize that it's my local dovecot server that adds these
>cur/new/tmp directories.  And yes, my local maildir is served by a
>local
>Dovecot server.

OK, so the problem is that you have a top-level maildir on the local side, and it (correctly) attempts to create a remote top-level folder then. Which your remote IMAP server does not allow. (I wonder if there actually is a remote top-level maildbox on your server, probably not).

So, IF you actually hava a top-level local folder that cannot be created on the remote side, the correct way to handle it would be to either add a:
folderfilter= lambda f: f is not ""
to your local repository rules (do try if empty string works, or if you have to use "." or "/") to prevent the local top-level folder from being synced. Does that work for you?

Or to nametrans the local top-level to a place that is allowed on the remote side.

>The problem here is that the remote server is saying that it disallows
>creating a directory named '/'.  Is the server I am using "special" in
>refusing the creation of a folder named '/'?  That would be unfortunate
>because it's a Zimbra server, and it's quite popular.  I have tried the
>same thing on a dovecot 2.1.9 server and it forbids it too.

Often, IMAP servers require a special prefix, such as INBOX for their folders. So creating a top-level mailbox can well be prohibited by a server. I believe Yahoo uses Zimbra, so I might be able to check with my yahoo account.

>Well, if a nametrans rule resolves to an path in the context of the
>remote repository, I'd say that means "do not sync this repository".
>Otherwise, what other reasonable meaning would that have?

Sorry, I don´ t get this. a) we cannot silently drop or ignore syncing any folders if it leads to an error. And you local top-level folder does translate into a mailbox name on the other side, so just not creating it, sounzds wrong to me as well.
I believe the correct thing here, is to force the user to filter out said top-level mailbox.  The one thing we can do, is to give back better error messages that help the user to find the cause, rather than the unhelpful #thing we spit out now.


Thanks for your patch. This is much appreciated (especially getting your hands dirty with code :-))
I have 2 problems with it:
1) Top-level mailboxes are valid and used in the real life. That´s why we cannot simply ignore it. People do use that.

2) It seems just like a very complicated way to emulate the folderfilter rule I specified above. Am I right? This lets you filter out any folder quite easily (and filtering out existing top-level mailboxes too).

If this is the case, this seems more like a documentation issue than anything else.

Now, there is the possibility that the remote IMAP server does have a top-level mailbox and we fail to recognize it as existing. In this case, this were a real bug that we should be solving.

Sebastian

-- 
Sent from my tablet. Please excuse my brevity.