Occasionally weird behaviour with mboxes

[Michael Menge]

Hi,

allowallsubscribe: 1 in imapd.conf may solve your problem

Quoting Dan White <dwhite at olp.net>:

> On 19/05/10 08:37 +0200, Lorenzo Marcantonio wrote:
>> It's some times a few user of mine lament a strange behaviour: they see
>> 'gray' folders in thunderbird, but it happens *very* rarely... btw these
>> people have 6-10 GB of mail in their folders if it can be useful!
>>
>> A protocol trace revealed that, indeed, the mbox is sent as noselect:
>>
>> ---------- crbrmt Tue May 18 08:52:24 2010
>>
>> <1274165544<3 namespace
>>> 1274165544>* NAMESPACE (("" ".")) (("Other Users." ".")) (("Shared  
>>> Folders." "."))
>> 3 OK Completed
>> <1274165544<4 list "" "%"
>>> 1274165544>* LIST (\Noinferiors) "." "INBOX"
>> * LIST (\HasNoChildren) "." "APIndustria"
>> * LIST (\HasChildren) "." "Aziende"
>> * LIST (\HasNoChildren) "." "Bozze"
>> * LIST (\HasChildren) "." "Consulenti"
>> * LIST (\HasNoChildren) "." "Curriculum"
>> * LIST (\HasNoChildren) "." "Drafts"
>> * LIST (\HasChildren) "." "Fornitori A-F"
>> * LIST (\Noselect \HasChildren) "." "Fornitori G-Z"
>> * LIST (\HasNoChildren) "." "GEI"
>> * LIST (\HasNoChildren) "." "IN SOSPESO"
>>
>> ... so I presume that's the reason why it's shown in gray and the users
>> don't see the contents...
>
> \Noselect should be returned for hierarchically delimited 'placeholders'
> that are not actual mailboxes.
>
> For instance, creating the mailbox INBOX/Work/Jim without first creating
> INBOX/Work would make INBOX/Work non selectable, with children.
>
> Or another scenario is that both INBOX/Work and INBOX/Work/Jim exist but
> someone accidentally (through mouse slip?) deleted INBOX/Work, but then did
> not delete INBOX/Work/Jim.
>
>> Other weird behaviour (possibly related) is that sometimes subfolders
>> 'disappear' from the tree... closing and reopening the parent shows them
>> again; and from alpine sometimes saving messages gives a 'mailbox not
>> present', but retrying after a while works!
>>
>> All off these are very spurious (I did a week of traces before seeing
>> the one shown before) but really annoying... what could be the reason?
>>
>> It seems from a cursory look at the source that 'Noselect' is only for
>> 'reserved' boxes (whatever they are) or am I missing something? Also
>> I see no errors in the logs and I assigned plenty of descriptors to
>> cyrus processes (65535); this is the second server I see this behaviour
>> on, so I would exclude flaky hardware...
>>
>> Server is cyrus 2.3.14 on linux 2.6
>>
>> Any idea/assistance could be useful
>
> --
> Dan White
> ----
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
>




--------------------------------------------------------------------------------
M.Menge                                Tel.: (49) 7071/29-70316
Universität Tübingen                   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung          mail:  
michael.menge at zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5339 bytes
Desc: S/MIME Signatur
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20100520/57dcec4e/attachment.bin