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
