[gmane.mail.imap.offlineimap.general] Re: [PATCH] Re: Avoid trying to synchronize folders that have empty names
Sebastian at SSpaeth.de
Sun Sep 9 09:43:50 BST 2012
Dodji Seketeli <dodji at seketeli.org> wrote:
>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
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.
Sent from my tablet. Please excuse my brevity.
More information about the OfflineIMAP-project