Complete.Org: Mailing Lists: Archives: offlineimap: July 2008:
Re: OfflineIMAP and KMail
Home

Re: OfflineIMAP and KMail

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: offlineimap@xxxxxxxxxxxx
Subject: Re: OfflineIMAP and KMail
From: Josh Rickmar <joshua_rickmar@xxxxxxxxxxx>
Date: Mon, 14 Jul 2008 10:23:44 -0400

Sorry, forgot to send it to the list, not to you directly.

Josh Rickmar wrote:
> OK, well, I finally got so fustrated with my own configurations for 
> Dovecot and OfflineIMAP (which I based on the sample configurations) 
> that I just blew them away and copy/pasted yours.  At least now I'm 
> finally getting some of the errors you described. :P
> 
> First of all, I had to comment out the last line in my ~/.offlineimaprc 
> ('foldersort=mycmp') because I don't have it in my custom pythonfile. Is 
> this important?
> 
> Also, I am now getting the error with calling mkdir('.'), and am looking 
> to patch it.  I have my OfflineIMAP (6.0.0) installation in 
> ~/offlineimap/, and the only Maildir.py files I have are in 
> ~/offlineimap/offlineimap/folder/Maildir.py and 
> ~/offlineimap/offlineimap/repository/Maildir.py.  After doing a search 
> through them, neither of them contain a 'mkdir('.')' line.  Could you 
> help me with patching this, or should I just downgrade to 5.99.4 and use 
> your patch? (I don't mean to force you to upgrade to 6.0.0 just to help 
> we with this problem.)
> 
> Hope I can get this figured out soon, right now I'm stuck using 
> Thunderbird.  Basically there are three main reasons why I dislike it:
> 
> 1) It's slow.
> 2) Horrible integration (read: none) with KDE
> 3) And it stores its mail in mbox *shivver*
> 
> 
> David L. Emerson wrote:
>> yeah, that very thing frustrated me, too. I couldn't get dovecot to 
>> look in the right places for my mail folders -- heaven knows why. 
>> Maybe the dovecot mailing list would be a good place to ask.
>> Anyway, I never got dovecot to behave properly, so I went with the 
>> offlineimap nametrans, which has worked great.
>>
>> My custom offlineimap.py looks something like this:
>>
>> import re
>> dovecot_kmail_re = re.compile('^\.?(inbox[./])?', re.IGNORECASE)
>>
>> def fix_dovecot_kmail (folder_nm):
>>   if folder_nm.lower() in ('inbox', '.inbox', '.'):
>>     return '.'
>>   return dovecot_kmail_re.sub('.INBOX.', folder_nm, 1)
>>
>> And of course as I mentioned, my ~/.offlineimaprc contains
>> pythonfile = /path/to/offlineimap/config/offlineimap.py
>> # and for each account's remoterepository section,
>> nametrans = fix_dovecot_kmail
>>
>> What the first "return" line does is map the inbox to the maildir (not 
>> to a subdirectory of it). So if the maildir is /home/david/mail, then 
>> /home/david/mail will contain {cur,new,tmp} folders for inbox: so 
>> /home/david/mail/. is my inbox folder.
>>
>> All other folders are made subfolders of the inbox by the compiled re 
>> which is run by the second "return". They thus are named, e.g., 
>> /home/david/mail/.INBOX.Subfolder/cur etc. So that's how my mailboxes 
>> are set up ... not the best design (I don't really like it, anyway) 
>> but dovecot seems to like it, so I guess that's what's important.
>>
>> Of course, the trouble is that when offlineimap first creates an 
>> account, it receives the foldername '.' from the nametrans, attempts 
>> to call mkdir('.') and crashes (line 100 of Maildir.py) So I patched 
>> offlineimap so it would never call mkdir on '.' (which is incidentally 
>> why I'm still using 5.99.4)
>>
>> Sorry I can't really help you solve the real problem, which is dovecot 
>> behaving badly, but maybe my workaround will work for you too. Good luck!
>>
>> ~David.
>>
>>
>>
>> P.S. I've never had an issue before with those =20 things at the end 
>> of *my* messages. I've seen them on other people's messages many 
>> times. Dunno what made them suddenly appear ... hopefully they will 
>> disappear just as quickly!
>>
>>
>>
>> On Saturday 05 July 2008 6:29 am, Josh Rickmar wrote:
>>> Thanks for your response.
>>>
>>> I tried to get this fixed using your recommendations, but its not
>>> quite working the way I expected it to. :)
>>>
>>> [...]
>>
>>
> 




[Prev in Thread] Current Thread [Next in Thread]