[Dovecot] dot-containing foldernames \HasNoChildren bug ?

[Samuel Kvasnica]

 Hi Timo,

in addition to my last message regarding public folders I did some more
testing on the shared folder issue.

It seems like there are 2 separate issues, both related to misbehaving
LSUB command but different.

For a shared folder a command like e.g.:

, lsub "" "Shared/dot.user/dot_share"

will return nothing, even if this folder is subscribed because
list_escape (out of some strange reason) gets an empty prefix and
wrongly escapes the user name dot.user to dot\2euser.

For the LIST command on other hand it works, because it first fails with
zero prefix but then all namespaces are probed which
will succeed for prefix "Shared/dot.user". The difference seems to be
the condition in cmd-list.c, list_namespace_init()
testing for some subscription flags.

Could you give some hint, whether a quick workaround is possible ? I
have a feeling the listescape plugin is implemented at wrong place,
somewhere directly above the storage stuff or as an virtual storage
interface would be cleaner ?

regards,

Sam

On 08/06/2010 10:40 PM, SK wrote:
> On 08/06/2010 09:04 PM, Timo Sirainen wrote:
>> On Fri, 2010-08-06 at 20:41 +0200, SK wrote:
>>   
>>> Ok, now it does not crash anymore,  But...: I cannot see shared folders
>>> for users containing a dot (e.g. the "shared.user" above)
>>> on open-exchange webclient. If I disable the listscape plugin, the
>>> folder is visible. Something more is still broken. Any idea where to look ?
>>>     
>> I'm not sure if this is fixable. I'll look into it later..
>>
>>   
> Well, that would be an essential showstopper for the migration from
> scalix to dovecot in our setup.
> But I don't believe it is unfixable. I did some tcpdump logging in the
> meantime, The open-xchange client
> seems to rely heavily on the LSUB command which is different from e.g.
> thunderbird which seems to use mostly LIST.
>
> It appears that the dovecot replies for LSUB commands with '%' wildcard
> are different when listescape is enabled.
> Please have a look at the attached comparison. At least for the public
> folders it is pretty clear (even when not using dots there) and
> subfolders in public area are broken as well. I cannot find the clear
> difference for the shared folder case though, but more info comes later
> on... the public folder bug might be the key...